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Preface 


The  purpose  of  this  report  was  to  implement  the  D  lan¬ 
guage,  and  thereby  gain  some  insight  as  to  its  efficiency,  and 
to  a  lesser  degree  D's  usefulness.  This  analysis  extended  in 
part  to  the  D  machine,  from  which  the  language  was  drawn. 

Having  fallen  short  of  a  full  implementation,  this  thesis 
still  serves  to  provide  a  static  analysis  of  the  language 
design,  along  with  further  definition.  Discussed  is  D's  pur¬ 
pose,  its  history,  and  its  current  state.  Bach  section  is 
built  upon  the  previous  one;  therefore,  it  is  suggested  those 
who  read  it  start  at  the  beginning  (like  a  good  book).  With 
some  minor  modifications  to  D's  weaknesses,  D  has  the  potential 
to  become  a  widely  used  language. 

This  thesis  would  not  have  been  possible  were  it  not  for 
the  following  people  to  whom  I  wish  to  express  my  gratitude. 
First  to  Dr.  Harold  Carter.  Except  for  his  patience,  with  my 
procrasinating  ways,  and  guidence,  I'd  have  long  ago  gone  down 
a  road  of  no  return.  Secondly  to  Dr.  Panna  Nagarsenker,  whose 
constant  curiosity  provided  the  impetuous  to  keep  me  working, 
while  she  supplied  helpful  hints.  Thirdly,  I  wish  to  acknow¬ 
ledge  the  support  of  my  wife  Connie,  without  whose  encourage¬ 
ment  this  thesis  would  have  been  infinitly  greater.  Finally  my 
highest  thanks  goes  to  my  Lord  and  Savior  Jesus  Christ  whose 
divine  hand  placed  me  at  AFIT,  and  whose  grace  and  mercy 
enabled  me  to  accomplish  the  tasks  set  before  me. 


Kevin  J.  Shomper 
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Abstract 


In  a  continuing  effort  to  define  and  analyze  the  D  langu¬ 
age  a  partial  interpreter  has  been  built.  This  interpreter 
stresses  both  syntactic  and  semantic  error  reporting  in  order 
to  function  as  a  learning  aid  to  the  inexperianced  D  programmer. 
The  language  definition  is  completed,  with  the  exception  of  the 
accept  function  and  the  1  block  control.  All  error  checking  has 
been  accomplished  except  expression  type  checking. 

D  contains  weaknesses;  most  notably  in  its  class  construction 
Although,  this  is  a  perceived  problem  and  not  a  functional  one. 

It  is  reccommended  that  the  reader  be  familiar  with  both  Ada  an  C 
in  order  to  fully  grasp  the  ideas.  Follow  on  work  should  complete 
the  code  generation,  but  in  Ada  not  in  C.  Only  then  will  the  full 
potential  of  D  be  realized. 


Perceiving  current  architectures  to  be  inadequate  to 
the  task  of  modern  programming  problems  (5:1),  Captain 
Jennings  designed  an  architecture  and  a  language.  The  pur¬ 
pose  of  this  thesis  is  to  take  the  designed  language,  0,  and 
attempt  to  implement  it.  This  implementation  will  take  the 
form  of  an  interpreter  which  transforms  a  program  coded  in  D 
to  one  coded  in  C.  The  presentation  format  will  be  similar 
to  the  steps  one  would  follow  in  software  engineering:  1) 
present/define  the  problem,  2)  set  requirements,  3)  design 
the  system,  4)  code,  5)  verify  through  testing.  In  addi¬ 
tion,  a  separate  section  analyzing  the  language  will  be 
included  to  aid  the  reader  in  understanding  design  deci¬ 
sions,  as  well  as  provide  a  guide  to  programming  in  the  D 
language.  This  last  use  is  added  as  it  is  hoped  D  will  be  a 
fully  implemented  language  upon  the  completion  of  this  the¬ 
sis.  Lastly  a  section  presenting  the  differences  between 
the  designed  version  and  the  implemented  version  will  be 
included. 

The  Problem 

In  its  most  rudimentary  form  the  problem  addressed  is 
there  does  not  currently  exist  a  machine  upon  which  the  D 
language  is  implemented.  Prom  a  software  viewpoint  one  has 
basically  two  practical  methods  at  his/her  disposal  to 
achieve  the  task.  The  most  efficient  method,  apart  from 


keeping  an  experienced  staff  of  assembly  programmers  on 
hand,  is  compiling.  Compiling  is  a  process  of  breaking 
apart  a  high-order  language  (HOL)  program,  also  referred  to 
as  the  inpu  or  source  program,  into  lexical  units  called 
tokens.  Prom  these  tokens  a  machine  internal  structure  is 
formed,  such  as  a  tree  or  a  table.  This  structure  is  then 
reduced,  if  possible,  and  an  assembly  program  is  generated 
from  it.  The  specific  assembly  language  used  is  the  target 
language.  Further  optimization  may  be  done  at  this  point  by 
means  of  a  peephole  optimizer:  a  routine  in  the  compiler 
which  examines  a  small  section  of  the  assembly  code,  usually 
three  to  five  instructions  at  a  time,  and  deletes,  changes, 
or  adds  instructions  without  altering  the  program's  meaning. 
The  assembly  instructions  are  then  mapped  one  for  one  into 
machine  code  which  comprises  the  machine  executable,  seman¬ 
tic  interpretation  of  the  HOL  program. 

:  ..cept  in  rare  circumstances  is  the  machine  code  pro¬ 
duced  from  the  compiler  and  assembler,  the  latter  being  the 
software  which  conducts  the  mapping,  as  efficient  as  a  good 
assembly  programmer  could  produce;  although  with  the  speed 
of  today's  hardware,  efficiency  at  this  level  is  nearly 
never  an  issue  of  concern. 

The  second  method  of  implementing  a  HOL  through  soft¬ 
ware  would  be  by  interpretation.  This  is  similar  to  the 
compiling  process  described  above  in  that  an  equivalent 
program  in  another  language  is  generated  by  disassembling 


the  source  program.  Interpretation,  sometimes  called  trans¬ 
lation,  differs  by  attempting  to  match  the  grammars  of  the 
source  an  target  languages  by  function.  For  example  the 
declaration  of  variable  'x'  in  source  language  A  is  trans¬ 
formed  into  the  declaration  of  variable  'x'  in  target  lan¬ 
guage  B,  without  using  an  intermediate  structure.  Both  the 
source  and  target  languages  have  the  same  level  of  complexi¬ 
ty,  i.e.  each  are  HOL's  or  each  are  assembly. 

Considering  the  language  D,  the  target  HOL  will  then  be 
compiled  producing  the  necessary  machine  code.  This  implies 
that  a  compiler  must  eventually  be  available  for  the  final 
target  HOL. 

Though  less  efficient  interpreters  are  often  used  when 
a  compiler  is  unavailable  for  the  source  language.  Such  is 
the  case  with  D.  Having  been  born  less  than  one  year  ago  a 
complier  has  not  yet  been  constructed  for  it.  Since  compi¬ 
ler  construction  involves  a  considerably  greater  effort  then 
the  building  of  an  interpreter,  the  latter  route  was  chosen 
as  the  means  to  implement  D  at  this  time. 

BagfrCflund  on  the  Problem 

The  background  on  compilers,  parsing  methods,  and 
interpreters  is  extensive  and  current.  The  main  focus  of 
the  literature  search  will  be  on  efficient  methods  of  pars¬ 
ing,  tree  representations  of  data,  and  error  recovery  and 
reporting . 


The  backround  of  D  on  the  other  hand  is  scant.  The 


sole  source  of  documentation  on  the  language  may  be  found  in 
the  thesis  by  Capt.  Jennings,  completed  while  he  was  at  the 
Air  Force  Institute  of  Technology.  Though  information  on  D 
specifically  is  lacking,  a  partial  understanding  of  D  can  be 
achieved  through  an  understanding  of  it  predecessors,  namely 
C  and  Ada,  of  which  documentation  is  prevelent. 

Approach 

The  following  sequence  of  events  will  be  utilized  to 
obtain  a  solution  to  the  problem.  First  both  a  literature 
search  concerning  parsing  and  error  detection/recovery,  and 
a  detailed  analysis  of  D  will  proceed  concurrently. 

Error  detection  and  reporting  play  an  important  role, 
because  so  little  written  material  is  available  to  the  D 
user;  therefore  a  desired  quality  of  the  interpreter  shall 
be  to  produce  accurate,  and  easily  understood  error 
diagnostics . 

The  analysis  phase  will  cover  the  syntactic  structure, 
from  which  the  guidelines  for  the  parsers  construction  will 
stem,  and  the  heart  of  the  interpreter:  D's  semantics. 

Design  methods  will  follow  ideas  introduced  with  the 
advent  of  software  engineering  e.g.  Structured  Analysis 
Design  Technique  (SADT)  diagrams,  structure  charts,  and  data 
dictionaries.  And  shall  proceed  top-down  as  these  methods 
demonstrate. 

Coding  of  the  interpreter  has  been  determined  to  be  in 
the  programming  language  C.  The  pros  and  cons  of  this 
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decision  are  discussed  in  the  requirements  section 


Both  during  coding  and  when  the  program  is  running 
testing  will  be  conducted  in  order  to  verify  the  program's 
correctness.  The  testing  will  be  limited  to  correctness  and 
robustness  (how  well  does  it  handle  the  situations  it  finds 
itself  in).  There  will  not  be  a  statement  on  its  efficien¬ 
cy;  though  grossly  inefficient  code  will  be  considered  unac¬ 
ceptable.  Validation  will  be  confined  to  a  path-testing 
methodology  using  sample  D  programs. 

Literature  Review 

The  research  and  information  used  in  this  thesis  may  be 
grouped  into  three  sections:  1)  the  language,  2)  previous 
interpretive  work,  and  3)  methods  of  software  engineering. 

While  one  can  understand  how  to  program  using  D  by 
reading  Capt.  Jennings  thesis  alone,  a  greater  insight  to 
the  language  design  may  be  achieved  if  the  reader  has  a 
certain  familiarity  with  the  programming  languages  C  and 
Ada.  D  atempts  to  take  the  most  useful  of  Ada's  new  ideas, 
and  implement  them,  while  retaining  a  compact  language  simi¬ 
lar  to  C  (5:ii).  Jennings  thesis  is  necessarly  incomplete 
in  its  design.  This  is  not  a  criticism  of  the  work,  rather 
than  a  warning  to  readers  that  the  language  will  undergo 
further  definition,  and  minor  evolution  during  implemen¬ 
tation.  These  changes  may  cause  contridictions  to  arise 
with  earlier  writings.  Therefore  Jennings  thesis  serves  as 
a  good  introduction  to  D,  and  a  valuble  source  of  design 


answers,  but  should  not  be  used  as  a  programming  guide. 

The  second  area  of  research  involves  parsing  algo¬ 
rithms,  specifically  those  with  error  detection  and  recove¬ 
ry  methods.  The  method  chosen,  while  admittedly  not  the 
most  efficient,  implements  the  language  in  an  easily  under¬ 
stood  fashion  similar  to  Wirth's  PL/0  parser  (10:311). 

Other  methods  surveyed,  but  rejected  were  a  phrase-level 
recovery  scheme  (ref  4),  a  context  free  parsing  algorithim 
(ref  3),  and  error  methods  used  with  the  Helsinki  Language 
Processor  (ref  8).  The  justification  for  their  rejection 
will  be  included  with  the  implementation  section. 

Finally  the  design  process  was  shaped  by  L.J.  Peters 
book  Software  Design  i.  Methodologies  and.  Techniques:  as  he 
gave  the  best  description  of  a  structure  charts  uses.  Once 
more  the  reason  for  using  structure  charts  will  be  discussed 
in  the  following  section. 

Material  was  both  prolific  and  current  concerning  pars¬ 
ing  and  design  methods,  though  often  the  authors  attemped  to 
place  too  much  information  on  too  few  pages.  In  addition  it 
would  have  been  helpful  to  have  compared  Capt  Jennings 
thesis  with  other  written  work  on  D,  unfortunately  this  was 
not  possible. 
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Every  software  effort  which  performs  a  function  of  some 
use  other  than  introducing  a  student  to  programming  should 
include  a  phase  known  as  requirements  analysis.  In  this 
phase  the  system  is  carefully  studied,  and  from  this  inspec¬ 
tion  a  concise,  clear,  and  consistent  statement  is  generated 
as  to  what  the  system  will  do  (7:12),  or  intends  to  do. 

This  statement  (or  statements)  becomes  the  yardstick  by 
which  the  system  is  measured,  upon  completion,  to  guage 
whether  the  stated  goals  have  been  met.  Requirements  defin¬ 
ition  can  also  serve  a  purpose  with  an  unfinished  work  by 
providing  guidence  towards  the  intended  goal.  Therefore  it 
is  necessary  to  reduce  ambiguity  in  requirements  definition 
to  a  minimum  while  allowing  flexibility  for  unanticipated 
and/or  unavoidable  problems. 

The  D  to  C  interpreter  proposed  is  no  exception  to  the 
need  for  requirements  definition.  Broadly  speaking  the 
interpreter,  hereafter  also  referred  to  as  the  system,  has 
only  one  requirement;  it  must  input,  in  some  manner,  a 
program  coded  in  the  D  language,  determine  the  meaning  of 
the  program  structures,  and  produce,  as  output  an  equivalent 
program  in  C  source  code. 

Within  this  global  view  many  other  requirements  are 
evident.  The  method  used  to  present  them  here  will  be  to 
define  the  requirement;  then  follow  it  by  an  explanation  or 
justification  as  to  why  this  requirement  was  chosen. 


Why  £ 

As  stated  earlier  a  D  program  will  be  converted  into  C 
source  code.  Why  was  C  chosen,  as  the  target  language,  over 
more  common  languages  like  Pascal  or  FORTRAN,  or  Ada? 

First,  C  was  seen  as  superior  to  the  Pascal  and 
Fortran,  because  its  architecture  allows  it  the  same  or 
better  flexibility  and  power  than  the  other  languages  pos¬ 
sess  e.g.  pointer  arithmetic,  better  string  handling  rou¬ 
tines,  and  lower  level  I/O  providing  increased  functionali¬ 
ty.  Jennings  (the  author  of  D)  also  described  D  as  the 
successor  to  C,  indicating  a  greater  similarity  between  them 
<5:ii&117)  . 

Second,  while  Ada  is  capable  of  implementing  a  greater 
subset  of  D,  possibly  all,  than  is  C,  it  cannot  be  used, 
because  AFIT  does  not  have  an  Ada  compiler;  therefore  pro¬ 
grams  generated  by  the  system  would  not  be  subject  to  dynam¬ 
ic  testing.  Furthermore  the  quick  implementation  of  D,  at 
AFIT,  which  was  a  driving  force  behind  this  thesis,  would  be 
lost. 

In  addition,  preliminary  work  on  a  D/C  comparison  has 
been  completed  by  Capt.  Jennings.  Henceforth  C  emerges  as 
the  natural  language,  currently,  to  target  the  translation 
of  D. 

Another  requirement  involving  C  is  that  the  interpreter 
will  be  written  in  this  language.  This  follows  from  the 
decision  made  above  as  it  aids  the  system  engineer  by  allow- 
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ing  him/her  to  focus  on  two  rather  than  three  languages. 
Certain  languages  may  also  be  quickly  dispatched.  FORTRAN'S 
lack  of  structure,  poor  typing,  and  crude  string  handling 
make  it  a  ludicrous  choice  for  implementing  an  interpreter. 
Ada,  on  the  other  hand,  would  be  an  excellent  choice,  except 
for  the  lack  of  a  compiler.  It  is  therefore  eliminated  due 
to  insufficient  support  rather  than  a  deficiency  in  the 
language. 

Pascal  and  C  are  then  left  as  the  only  serious  conten¬ 
ders.  Both  are  more  than  sufficient  for  the  purpose  at 
hand,  but  C  has  a  greater  variety  of  I/O  and  string  handling 
functions  as  part  of  its  standard  I/O  package.  In  addition, 
C's  structure  lends  itself  to  the  use  of  the  UNIX  makefile 
facility,  which  is  a  time  saving  asset  to  programming. 

While  it  is  possible  to  model  Pascal's  arrays  in  order  to 
handle  strings  exactly  like  C,  and  alter  the  program  struc¬ 
ture  so  it  will  perform  as  well  under  makefile,  one  is  still 
using  C  in  an  ideological  sense.  Furthermore  Pascal  would 
still  be  lacking  in  I/O,  most  importantly  the  error 
handling. 

Finally  C  is  the  language  of  choice  for  current  archi¬ 
tectures  (5:102).  Hence  C  emerges  as  the  best  language 
available  for  this  project. 

System  Constraints 


A  Vax  11/780  running  the  Unix  operating  system  was 
chosen  for  this  project.  The  Unix  environment  provides  the 
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greatest  degree  of  portability  for  C  programs,  since  most  C 
users  are  on  a  Unix  system  (6:159),  and  Unix  has  become 
prevelent  in  the  last  few  years,  especially  in  school  sys¬ 
tems  (9:19)  where  this  interpreter  should  spend  its  life. 
Unix  also  provides  a  direct  connect  capability  between  the 
operating  system  and  the  program  through  system  calls  should 
this  be  necessary  (e.g.  file  creation  and  deletion). 

A  Vax  computer  was  chosen  as  AFIT's  most  convienient 
and  suitable  system  currently  supporting  Unix. 

The  interpreter  will  stand  alone  as  a  program.  This 
does  not  imply  that  it  will  be  one  large  file.  On  the 
contrary,  it  will  be  split  up  for  use  with  makefile,  but  it 
will  not  call  or  incorporate  other  programs  which  have  been 
previously  developed.  The  reason  underlying  this  is  trans¬ 
portability.  Reliance  on  other  programs  hinders  transporta¬ 
bility  by  forcing  additional  constraints  on  the  system.  If 
the  system  engineer  creates  dependencies  on  other  programs 
beyond  the  scope  of  his/her  control,  there  is  a  greater  risk 
that  another  location  desiring  the  system  will  not  have  the 
needed  additional  programs,  or  that  those  programs  cannot  be 
transported  to  that  installation.  Portability  will  be 
further  enhanced  by  requiring  all  code  sections  which  are 
non-standard,  e.g.  terminal  control,  operating  system  inter¬ 
faces,  etc.,  to  be  confined  to  separate  routines. 

This  does  allow  the  use  of  non-standard  programs  in 
designing,  implementing,  or  testing  the  system. 
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The  final  constraint  concerns  C's  inability  to  imple 


ment  all  of  D,  but  the  greatest  possible  subset  will  be 
implemented.  Furthermore  a  section  indicating  the  defi¬ 
ciencies  will  be  included  in  this  thesis. 

IlSfiX  Interface 

The  system  would  accomplish  its  formost  goal  if  valid  D 
programs  yielded  equivalent  C  code,  while  invalid  input  was 
indicated  by  any  abnormal  program  termination;  however  such 
a  system  would  receive  little  use.  Not  only  would  this  case 
be  diametrically  opposed  to  user  friendliness,  but  as  a 
learning  aid  it  would  be  atrocious.  A  proper  implementation 
given  valid  input  should  indicate  its  manipulation  of  exter¬ 
nal  files  as  a  minimum,  and  more  importantly  should  report 
error  conditions  in  a  manner  which  will  help  the  user  cor¬ 
rect  them. 

Most  programmers  need  little  experience  with  compilers 
before  they  realize  the  error  messages  produced  are  far  from 
adequate  (2:246).  For  example  the  C  compiler  supplies  such 
as  "syntax  error",  and  "illegal  character  134  (octal)";  or 
as  in  one  Pascal  compiler,  "error  in  type  of  standard  proce¬ 
dure  parameter".  Therefore  this  system  will  report  any 
detected  syntax  errors  along  with  the  parsers  view  of  where 
the  programmer  went  wrong.  This  in  no  way  guarentees  all 
errors  will  be  found;  though  a  program  containing  at  least 
one  syntax  error  will  generate  at  least  one  error  message  as 
soon  after  detection  as  possible.  Nor  will  it  insure  that 


valid  code  will  not  be  cited  as  containing  errors  if  it 
follows  code  with  errors,  as  the  recovery  phase  may  cause 
further  program  difficulty. 

It  is  recognized  that  this  is  a  vague  definition  of 
error  recovery,  but  quality  in  this  area  cannot  be  pinpoint 
ed.  Still  it  is  hoped  that  the  quality  will  be  sufficient 
to  provide  yet  another  learning  tool  for  the  beginning  D 
programmer. 

In  addition  detection  of  fatal  and  non-fatal  semantic 
errors,  e.g.  variable  type  checking  will  be  incorperated 
into  this  system.  Its  purpose  is  to  further  assist  the 
programmer  in  catching  subtle  mistakes.  Once  again  errors 
in  previous  sections  of  the  program  may  cause  a  cascading 
effect  throughout  the  program  resulting  in  a  greater  amount 
of  errors  reported  than  the  program  actually  contains. 

The  error  warning  itself  will  at  a  minimum  contain  a 
descriptor  defining  whether  the  error  is  fatal  or  non-fatal 
the  line  number  of  the  file  it  occurred  on,  and  the  reason 
for  the  error. 

Unix  Comparability  and  Program  lZ£ 

Since  this  system  is  being  developed  to  work  in  the 
Unix  environment,  its  invokation  and  file  classification 
will  follow  the  standard  Unix  style.  For  example,  like  the 
C  compiler,  this  program  will  be  ivoked  as  "dc  <file  name>* 
If  options  are  added  to  control  the  program's  control  or 
loquacity,  they  will  be  input  with  the  familiar 


"dc  -<option>  <file  name>" 

format  (9:230).  A  usage  message  will  be  incorperated  with 
the  system  informing  the  user  of  the  proper  command  syntax 


In  addition,  the  C  code  file  will  contain  a  '.c'  exten¬ 
sion.  If  the  input  file  has  a  '.d'  extension  (for  D  code)/ 
the  'd'  will  be  changed  to  'c'/  otherwise  a  '.c'  will  be 
added  to  the  input  name.  A  possible  option  would  be  for  the 
program  to  warn  its  user  if  overwriting  of  an  existing  .c 
file  would  take  place,  and  allow  the  user  to  route  the 
output  elsewhere. 

Other  Requirements 

The  question  as  whether  to  carry  comments  from  the 
input  program  to  the  output  program  or  not  is  an  opinionated 
one.  Arguments  can  be  made  for  either  side;  therefore  for 
preference  reasons  only  it  was  decided  to  discard  comments. 
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As  stated  earlier  D,  having  been  influenced  by  C,  shows 
many  glimpses  of  C's  rich  use  of  operators  as  well  as  its 
apparent  lack  of  form.  This  free  format  being  exhibited  by 
permitting  files  to  be  mere  collections  of  functions  with  or 
without  a  main  routine  for  an  entry  point.  D  follows  this 
structure,  and  indeed  adds  to  this  freedom  by  permitting 
unconstrained  organization  of  the  languages  four  file  types. 

Eilfi.  Order 

However  to  comply  with  the  assumption  that  one  pass  of 
the  interpreter  is  sufficient  to  obtain  the  program's  mean¬ 
ing  an  order  will  be  imposed  on  the  file  types.  An  ordering 
will  also  permit  greater  semantic  error  checking.  The  fol¬ 
lowing  constraints  will  be  added  to  the  D  language:  1)  all 
scalars  and  structures  must  be  defined  in  a  state  file 
before  use  in  any  other  file,  2)  all  variables,  operators, 
and  functions  must  be  declared  in  a  storage  file  before 
being  referenced  in  an  actor  file. 

Although  D  is  clearly  a  child,  or  at  least  in  the  C 
family  of  languages,  one  should  not  be  misled  into  thinking 
the  differences  are  insignificant.  On  the  contrary,  to  the 
casual  observer  D  appears  totally  unrelated. 

This  section  describing  the  language  will  begin  at  the 
bottom  with  the  primitive  language  symbols  and  will  continue 
upwards  to  the  file  types,  discussing  their  operation  and 
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interaction.  Henceforth  when  the  word  file  is  used  it 
refers  to  one  of  the  four  D  file  types,  state,  storage, 
actor,  or  bundle.  If  a  Unix  system  file  is  discussed  it 
will  be  so  named,  or  be  clear  from  its  context.  All  infor¬ 
mation  contained  in  this  section  is  derived  from  Capt. 

Jennings  thesis  (reference  5)  except  for  constraints  imposed 
on  D  due  to  the  lesser  capabilities  of  C.  Four  the  reader 
familiar  with  syntax  diagrams  these  are  provided  in  Appendix 
A.  Note  that  they  show  a  top-down  structure! 

Naming 

D  naturally  has  four  disjoint  name  spaces;  an  addition¬ 
al  name  space  will  be  created  to  prevent  name  collisions.  A 
further  constraint  of  eight  significant  characters  need  be 
placed  on  sets  which  allow  names  greater  than  eight  charac¬ 
ters.  This  is  due  to  the  limitations  of  C  as  it  is  imple¬ 
mented  on  a  VAX  11/780  system.  Should  this  program  be  run 
on  a  system  other  then  this  one  the  eight  character  limita¬ 
tion  may  not  apply. 

The  name  spaces  are  broken  into  the  following  sets. 

Keywords,  which  are  English  words  used  as  a  form  of  punctua¬ 
tion  to  enhance  the  program's  readability.  A  list  of  the 
keywords  is  provided  in  Appendix  B.  The  second  set  operator 
names  are  any  combination  of  one  to  three  operator  symbols. 

The  functions  and  precedence  of  the  operators  is  also  listed 
in  Appendix  B.  Variable,  structure,  and  function  names  make 
up  the  third  name  space.  These  are  strings  of  symbols  whose 
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maximum  length  is  determined  by  the  maximum  size  of  the 
terminal's  input  line;  although  names  of  this  length  are 
impractical.  The  string  must  begin  with  an  alphabetic  char¬ 
acter,  upper  or  lower  case,  and  be  followed  by  zero  or  more 
alphameric  characters  or  an  underscore.  The  fourth  name 
space  consists  of  literals,  perhaps  better  known  when  re- 
fered  to  as  constants.  Literals  follow  the  same  rules  as 
variable  or  function  names  except  the  first  character  must 
be  a  digit  or  an  underscore.  Since  their  value's  may  not 
change  within  an  actor,  they  must  be  initialized  upon  decla¬ 
ration.  Lastly,  the  fifth  space,  names  in  the  set  starting 
with  three  underscores,  or  _ ,  followed  by  alphameric  char¬ 

acters  is  generated  by  the  interpreter  to  circumvent  name 
collisions  due  to  the  smaller  C  naming  set.  The  actual 
mapping  of  C  reserved  words  and  operator  names  into  the 
fifth  set  is  described  later.  Literal  names  may  begin  with 
three  underscores  but  the  user  is  cautioned  against  this 
practice  as  it  can  only  lead  to  trouble. 

Comments 

The  language  supports  a  facility  whereby  the  user  may 
comment  his/her  program  as  good  coding  style  demands.  The 
punctuation  indicates  the  following  stream  of  symbols 
is  a  comment,  and  is  to  be  disreguarded  by  the  interpreter, 
or  in  the  future  the  compiler.  The  comment  is  ended  by  a 
line  terminator  symbol;  although  it  may  be  extended  over 
multiple  lines  with  the  line  continuation  character.  If 


III-3 


extended  the  following  line  is  all  comment;  in  other  words 
any  program  construct  placed  on  the  line  will  be 
disreguarded . 


Classes 

Two  classes  or  types  are  predefined  in  D.  The  first  is 
a  range  of  integers;  which  is  not  actually  defined  by  the 
language,  but  is  included  in  the  file  standard  definitions 
as  int  or  integer.  The  size  of  the  range  is  dependent  upon 
which  system  the  the  language  is  implemented  on.  Standard_ 
definitions  must  be  shared  with  all  files  accessing  integers 
unless  the  user  wishes  to  define  his/her  own  set.  Further¬ 
more  the  interpreter  will  be  designed  so  that  if  there 
exists  a  file  called  stndrd_def  in  the  users  workspace  it 
will  be  accessed;  otherwise  a  generic  standard  definition 
package,  to  be  described  later,  will  be  used.  The  default 
for  all  files  without  a  link  to  a  standard_def initions  file 
will  be  the  generic  one. 

The  second  class,  predefined  for  expressions  only,  is  the 
quoted  literal.  These  are  either  single  characters  surrounded  by 
reverse  apostrophies,  e.g.  'CHARACTER',  or  character (s)  surround¬ 
ed  by  double  quotes,  e.g.  "one  or  more  characters".  Non-print- 
able  control  and  formatting  characters  are  not  permitted  in 
quoted  literals. 

Note  that  in  order  to  define  a  variable  to  be  of  the 
quoted  literal  type  one  need  define  the  class  in  a  state 
file  first  using  the  class  abstraction  operator.  An  example 


of  this  is  provided  at  the  end  of  this  section  where  a 
demonstration  and  explanation  of  the  language  is  given. 

OpaiLatprs 

Three  operators  are  predefined  in  the  D  language.  The 
remainder  are  the  responsibility  of  the  user,  unless  a 
standard  definition  package  is  used.  Those  which  need  not 
be  defined  are  the  assignment  operator,  integer  addition, 
and  integer  subtraction.  From  these  three  must  all  the 
other  operators,  both  arithmatic  and  logical,  familiar  to 
users  of  other  languages,  be  defined. 

The  assignment  operator,  denoted  takes  the  value 

of  an  expression  on  its  left  and  assigns  that  value  to  the 
logical  name  on  its  right  if  the  classes  match.  If  the 
classes  do  not  match  a  class  conversion  will  take  place  if 
possible,  and  the  assignment  will  be  made;  otherwise  an 
error  will  be  the  result  of  the  assignment.  The  class 
conversions  possible  are  integer  to  character,  floating  or 
fixed  point  to  integer,  floating  point  to  fixed  point,  and 
vice  versa.  The  rules  for  the  conversions  are  the  ASCII 
character  set,  truncation,  and  rounding  respectively.  All 
other  class  conversions  must  be  user  defined. 

Integer  addition  and  subtraction  are  denoted  '+'  and 
'  respectively.  And  although  the  programmer  could  denote 
multiplication  by  '/'  and  division  by  it  would  be  wise 
to  stay  with  preconceived  ideas  concerning  the  matching  of 
operators  and  their  functions. 


Examples  of  operator  definitions,  done  so  in  actor 
files,  will  be  demonstrated  at  the  end  of  this  section. 


Punctuation 

Before  continuing  further  it  should  be  noted  that  the 
heart  of  the  D  language  is  contained  within  its  large  punc¬ 
tuation  set,  of  which  keywords  are  a  part.  A  description  of 
this  set,  keywords  excluded,  will  aid  the  reader  in  under¬ 
standing  the  language  to  follow.  Assimilation  of  the  punc¬ 
tuation's  meaning  may  be  facilitated  if  the  reader  is  famil¬ 
iar  with  three  of  the  four  D  file  types. 

state  files  are  where  variables  and  structures  are 
defined.  For  example: 

rational  ::  {  int  :  numerator 
/ 

int  :  denominator 

} 

would  define  a  rational  to  be  a  structure  composed  of  two 
integers  separated  by  a  '/'.  Rational,  now  defined,  becomes 
an  object  class  like  integer.  Readers  familiar  with  the 
programming  languages  C  or  Pascal  may  liken  the  state  defin¬ 
ition  to  C's  typedef  or  Pascal's  type  declaration. 

The  Storage  file  creates  variables  of  the  types  speci¬ 
fied,  or  declares  the  input  and  output  types  of  operators 
and  functions.  The  former  being  like  the  var  in  Pascal  or 
the  variable  declaration  in  C  e.g.  int  name.  The  latter  is 
similar  to  the  type  declaration  preceding  functions  in  C, 
and  of  it  arguments  following  the  function  header.  An 


example  declaring  'm*  and  'n'  to  be  rational  variables#  * i * 
to  be  an  integer  variable  and  to  be  an  operator  accept¬ 
ing  rational  arguments  and  yielding  an  integer  result 
follows: 


rational  :  m#  n 
integer  :  i#  *  rational 

With  the  above  declaration  i  *  m  *  n  is  a  valid  expression. 

Actor  files  define  operators  and  functions  and  are  the 
only  files  to  contain  program  statements#  after  declaring 
their  input  and  output  variables. 

Table  1  describes  the  role  punctuation  plays  in  each  of 


the  three  files 


Table  I:  Description  of  Punctuation  Symbols  (5:49) 


SAD 

symbol  files  meaning 


U 


S  delimits  structure  definitions 

A  delimits  blocks 


U 


() 

) 

( 


if 


# 

@ 

$ 


SAD  denotes  an  array  by  following  a  <name> 
d  d  D  with  an  index  range  optionally  specified  by 
scalar  value  within  square  brackets 
e  A  e  with  an  index  optionally  specified  by  a 
scalar  value  within  square  brackets 

e  A  e  controls  expression  precedence 

S  suppress  zeros  to  right 

S  suppress  zeros  to  left 

SAD  line  continuation  character 

d  d  D  <class>  tor  type!  delimiter  —  declaration 

S  A  <class>  lor  type]  delimiter  —  definition 

SAD  comment  initiator 

e  A  e  single  symbol  quoted  literal  delimiter 

e  A  e  string  quoted  literal  delimiter 

e  A  e  possession  indicator 

d  d  D  creates  pointer  to  declared  class 
e  A  e  obtains  object  referenced  by  pointer 

e  A  e  address  abstraction  on  following  <name> 
d  d  D  class  abstraction  on  following  <name> 

A  delimits  guard  expressions 

A  selects  block  behavior 


<blank>  A 

;  A 

\  A 


goto  next  line  of  block 

goto  next  open  line  of  block 

goto  beginning  of  block  and  reexecute 


KEY:  S  -  contained  in  state  file 

A  -  contained  in  actor  file 
D  -  contained  if  storage  (Declaration)  file 
e  -  only  appears  in  expressions  [S  or  D  file] 
d  -  only  appears  in  declarations  [S  or  A  file! 


Expressions  in  D  take  on  many  forms  these  being  a 
literal  or  quoted  literal,  a  logical  name  optionally  pre¬ 
faced  by  an  two  expressions  bound  by  an  operator  or  an 

expression  with  a  prefix  or  suffix  operator.  Others  are  an 
expression  in  parentheses,  a  function  name  optionally  fol¬ 
lowed  by  an  expression,  the  reserved  word  "null"  or  an 
accept  function.  All  expressions  are  reducable,  given  the 
values  of  their  respective  subexpressions,  to  a  single  value 
of  a  specific  class  subject  to  the  rules  of  operator  prece¬ 
dence  and  binding. 

Punctuation  preceding  a  logical  name  specifically 
'#',  and  parentheses  bind  the  tightest,  or  have  the 
highest  precedence.  Next  in  the  binding  hiarchy  are  func¬ 
tion  names,  than  operators.  The  operator  precedence  is 
determined  by  the  right  most  operator  in  the  name,  and  is  as 
follows: 


1,  *  highest  operators  on  the 

*,  /  same  level  have 

~,  %  the  same  precedence 

+  ,  - 
& ,  I 
<,  > 

=  lowest 


For  example  the  operators  +■*,  **+,  =/ I ,  and  II®  are  in 
order  from  highest  to  lowest. 

If  an  precedes  a  logical  name  the  value  returned  is 
the  address  of  that  logical  name.  In  other  words  the  value 
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returned  is  equivelent  to  that  which  a  pointer  pointing  to 
that  logical  name  would  have.  A  is  the  inverse  of  an 

•  @ .  If  a  '#'  precedes  a  pointer  the  value  returned  is  the 
value  of  the  object  pointed  to.  One  could  say  logical_name 

*  #@logical_name.  The  expression  pointer  =  @#pointer  is 
valid  though.  Multiple  #'s  may  precede  pointer  in  order  to 
follow  a  chain  of  pointers;  although  too  many  will  return  a 
"null"  value.  The  number  of  valid  #'s  the  user  may  string 
together  is  dependent  upon  the  system. 

Array  names  if  not  followed  by  the  square  brackets 
constitute  pointers  to  the  array,  specifically  the  first 
element  in  the  array. 

Components  of  a  structure  can  be  accessed  individually 
through  the  use  of  the  punctuation.  For  example  given 
the  definition  for  a  rational  number  described  earlier  one 
could  assign  k,  if  it  were  an  integer,  to  the  numerator  of 
the  rational  number  m  through  the  expression 
k  **  m'numerator. 

A  pointer  should  have  the  value  "null"  when  it  is  not 
pointing  to  anything.  The  user  should  take  care  when  as¬ 
signing  a  pointer  to  null.  For  if  the  object  which  that 
pointer  referenced  is  not  referenced  by  another  pointer  it's 
lost. 

Finally  multiple  assignments  in  an  expression  are  al¬ 
lowed  by  D;  i.e.  varl  *  var2  *  var3  *  expression  is  syntac- 
ticly  correct. 
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D  is  a  very  compact  language  having  only  four  statement 
types.  The  expression  already  discussed  is  the  first  of 
them.  Second  is  the  return.  This  statement  is  a  semantic 
twin  of  the  C  return  statement.  It  terminates  the  current 
actor  and  returns  to  the  calling  function.  The  statement 
allows  an  optional  expression  to  be  evaluated  and  its  value 
become  the  formal  return  variable.  A  function  if  defined 
without  an  output  variable  will  generate  an  error  if  it 
contains  a  return  with  an  expression. 

The  third  statement  is  the  "new"  function.  Taking  a 
pointer  as  an  argument  it  dynamically  creates  a  storage 
location  of  the  class  #pointer.  Alternately  said,  given  the 
class  of  the  object  which  the  pointer  is  allowed  to  point  to 
another  object  of  that  class  is  created.  The  pointer  then 
receives  the  created  objects  location  as  its  value,  and  any 
object  previously  referenced  by  pointer  is  lost.  That  is, 
unless  another  pointer  had  also  referenced  the  object. 

The  fourth  statement  type,  a  block  or  compound  state¬ 
ment,  is  of  an  importance  to  deserve  a  section  of  its  own. 

Blacks, 

Syntactically  a  block  is  a  header  followed  by  linkage 
and  one  or  more  lines  inside  curly  braces.  Although  it  is  a 
statement,  statements  may  only  appear  inside  a  block,  with 
the  exception  of  the  expression.  Blocks  appear  only  inside 
actor  files  to  define  the  actor.  Primed-  with  this  the 
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subconstructs  in  the  block  will  be  identified. 

The  Header.  The  block  header  consists  of  a  label  and 
an  optional  selector.  The  label  follows  the  same  naming 
conventions  for  function  names.  It  provides  part  of  the 
jump  capability  as  any  statement  within  that  actor  may  jump 
to  the  beginning  or  end  of  a  labled  block  using  the 
continuation . 

The  selector  is  an  expression;  if  present  the  value  of 
the  expression  becomes  the  value  a  guard  must  have  to  be 
declared  open.  If  the  selector  is  not  present  any  positive 
guard  value  is  declared  open.  While  all  negitive  guard 
values  are  closed. 


Block  Linkage.  A  discussion  on  linkage  is  presented 
later,  but  it  should  be  mentioned  renaming  may  not  occur 
inside  of  a  block. 

Lines.  Lines,  in  D,  are  charged  with  the  responsi¬ 
bility  of  program  control.  Consisting  of  a  statement,  op¬ 
tionally  prefaced  by  a  guard,  and  followed  by  a  continuation 
symbol,  they  emulate  the  three  basic  control  structures, 
conditional,  sequential,  and  iterative. 

Conditional  control  is  implemented  through  the  guard. 
Syntactically  an  expression  followed  by  a  the  guard  is 
evaluated;  if  it  matches  the  value  in  the  first  surrounding 
block's  selector  (or  the  default  values,  non-zero  numbers, 
if  no  selector  is  present)  the  statement  following  the  guard 
is  executed.  Otherwise  control  is  passed  to  the  next  line 
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for  guard  evaluation. 

Sequential  control  may  be  forced  and  iterative  control 
is  handled  by  continuations.  They  consist  of  an  optional 
label  followed  by  one  of  four  continuation  characters.  The 
optional  label  indicates  the  actions  of  the  continuation 
shall  be  applied  to  the  named  block.  If  a  label  is  not 
present  the  current  block,  or  first  enclosing  block  is  used. 

The  continuation  characters  are:  1)  <blank>,  denoting 
forced  execution  of  the  immeadiatly  following  statement 
reguardless  of  whether  its  guard  is  open,  closed,  or  non¬ 
existent,  2)  a  indicating  normal  control  flow,  as  in 
other  languages,  to  the  next  open  statement,  3)  a  'V  which 
directs  the  program  to  reenter  the  block;  including  reeval¬ 
uation  if  the  selector  and  guard  values  if  any  exist,  and  4) 
the  symbol  terminates  the  block. 

Files 

Files  may  now  be  discussed  in  detail,  along  with  their 
respective  components  and  fuctions.  A  D  program  is  divided 
into  four  file  types,  two  to  define  objects,  one  to  declare 
them,  and  one  to  organize  the  files.  Each  file  need  not 
repose  in  a  separate  Unix  system  file.  On  the  contrary,  D 
files  should  be  combined  in  Unix  files  to  create  functional 
programs.  The  keywords  state,  storage,  actor,  and  bundle 
determine  the  type  of  file  which  follows.  Each  file  is  then 
given  a  name,  which  may  be  used  to  reference  the  file  by 
another.  Referencing  may  only  take  place  between  files  in 
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the  same  Unix  file,  or  mutiple  Unix  files  bound  together 
through  the  use  of  the  Unix  linclude  facility.  A  line 
terminator  separates  the  file  declaration  from  its  linkage, 
following  which  is  the  file  body.  It  is  the  body  where  the 
file  types  are  unique.  Every  file  is  then  terminated  by  a 
period  appearing  on  its  own  line,  with  nothing  but  white 
space  preceding  it. 

Linkage.  Linkage  is  the  means  whereby  modules  communi¬ 
cate  with  each  other.  It  provides  three  functions  to  the 
user,  sharing,  copying,  and  renaming. 

A  file  may  gain  access  to  another  by  including  the 
desired  file's  name  following  the  share  keyword.  This  ac¬ 
tion  permits  the  naming  file  to  reference  any  object, 
whether  variable,  function,  or  operator,  in  the  named  file. 
The  link  created  is  one  way,  unless  a  corresponding  share 
statement  exists  in  the  named  file;  although  this  would 
rarely  be  necessary.  Communication  between  files  may  occur 
when  two  or  more  files  share  a  common  modifiable  area,  i.e. 
a  storage  file.  The  definition  files,  state  and  actor,  are 
usually  shared. 

The  copy  function,  used  in  the  same  format  as  share, 
also  provides  access,  but  to  an  identical  copy  rather  than 
the  original  file.  There  is  no  limit  to  the  number  of  times 
a  file  may  be  copied;  therefore  if  five  files  each  copy 
another,  five  individual  copies  are  produced.  Storage  files 
are  often  copied  to  prevent  other  files  from  accessing  and 


III-14 


possibly  destroying  data,  or  they  may  be  shared  to  provide 
interfile  interaction.  Copying  a  definition  file  is  equiva¬ 
lent  to  sharing  it,  since  modification  on  these  files, 
during  execution,  is  not  possible.  Bundle  files  may  be 
shared  or  copied.  The  result  is  the  respective  function 
over  all  files  named  within  the  bundle  file.  For  example, 
if  file  x  shares  bundle  file  y,  and  y  contains  files  a,  b 
and  c,  then  it  is  as  if  x  had  shared  a,  b,  and  c,  calling 
each  one  by  name. 

Renaming  provides  to  user  with  the  ability  to  change  an 
objects  name  to  a  more  desirable  one.  The  idea  was  born  as 
a  way  to  facilitate  program  readability  when  linking  utility 
routines,  which  often  have  meaningless  names.  Assume,  for 
example,  a  storage  file  with  a  structure  for  personnel 
called  "person",  and  a  scratch  variable  "i".  Let  "person" 
contain  three  data  areas,  datal,  data2,  and  data3,  and 
further  assume  this  storage  file  is  being  linked  to  an  actor 
which  performs  an  employee  payroll  function,  which  already 
has  a  variable  "i"  declared.  To  add  clarity  and  to  avoid  a 
naming  ambiguity  the  user  may  rename  as  follows; 

rename  i  j 

rename  person’datal  employee'name 
rename  person’data2  employee'position 
rename  person'data3  employee'address 

The  question  concerning  which  "i"  would  be  used  if  the  user 
forgot,  or  did'nt  care  to,  rename  "i"  will  be  left  until  the 
design  of  the  interpreter.  As  mentioned  earlier,  renaming 
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may  not  occur  in  block  linkage. 

State  Files.  The  state  file,  as  mentioned  earlier,  is 
similar  in  it  function  as  the  C  typedef.  After  linkage  the 
user  defines  scalars  as  a  range  of  integers,  or  structures 
from  known  templates.  Once  defined  the  scalar  or  structure 
names  become  known  classes  from  which  other  objects  may  be 
defined  or  declared.  Scalars  are  defined  by  providing  a 
name,  the  double  colon  punctuation,  and  a  pair  of  integers, 
the  latter  being  greater,  separated  by  a  double  period.  The 
scalar's  range  is  inclusive  of  the  integers  given.  A  short¬ 
hand  notation  is  available  on  occasion  by  supplying  a  single 
integer.  The  range  then  lies  between  the  value  specified 
and  zero  inclusive. 

Structures  consist  of  a  structure  name,  the  double 
colon,  and  curly  braces  surrounding  the  components.  Each 
component  may  be  a  class  colon  declaration,  discussed  under 
storage  files,  or  a  mixture  of  printable  symbols  (psymbol  in 
the  syntax  diagrams,  Appendix  A)  and  periods,  or  the  paren¬ 
theses,  meaning  supression  of  zeros.  If  a  variable  is 
declared  as  a  structure  containing  only  one  component,  the 
component  may  be  referenced  by  the  variable  name  only.  An 
example,  of  a  structure,  has  been  given  under  the  subsection 
Punctuation  and  the  paragraph  beginning  with  State,  or  the 
reader  may  wish  to  reference  the  language  example  given  at 
the  end  of  this  section. 

Storage  Files.  Used  to  declare  or  instantiate  from 
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classes  defined  in  state  files  the  storage  file  body,  that 
section  which  lies  between  linkage  and  the  terminating  per¬ 
iod,  consists  of  at  least  one  of  the  following  set  of  sym¬ 
bols.  Each  set  occupies  its  own  separate  line.  The  set  is 
a  defined  class,  a  single  colon,  and  one  or  more  declara¬ 
tions,  which  are  object  names,  separated  by  commas,  with 
their  optional  initialization.  The  format  of  the  set  is 
similar  to  the  Pascal  var  statement.  Differences  exist  in 
that  the  class  precedes  the  colon.  The  class  abstraction 
operator,  discussed  in  detail  under  actor  files,  may  be  used 
to  provide  the  class.  The  other  break  in  similarity  is 
Pascal's  inability  to  perform  variable  initialization  with 
instantiation . 

Optionals  symbols  may  procede  and  succeed  the  object 
name,  except  function  and  operator  names,  to  create  new 
types.  Names  proceded  by  a  are  declared  to  be  pointers 
to  the  named  class,  while  names  followed  by  ' t  ] '  with  an 
optional  integer  between  the  brackets  are  declared  to  be 
arrays  of  that  class.  The  integer  determines  the  size  of 
the  array.  Should  one  not  be  present  the  array  is  an  inde¬ 
finite  size.  The  pointer  symbol,  '#',  binds  tighter  then 
the  array  brackets;  therefore  an  object  declared  as  so: 
class  :  #object[5J  is  an  array  of  five  pointers,  which  may 
point  to  objects  of  type  class.  If  an  array  is  initialized 
all  its  members  are  assigned  the  initializing  value. 

Functions  and  operators  need  also  be  declared.  The 
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format  is  the  same  as  for  objects,  except  the  input  argument 
class  follows  the  function  or  operator  name.  The  function's 
or  operators's  class  is  defined  by  the  class  of  its  return 
value.  If  a  function  has  no  input  or  output  values  the 
keyword  "null"  is  inserted  as  the  class  for  the  missing 
arguments . 

Actor  Files.  Having  now  the  ability  to  define  objects, 
and  declare  objects,  functions,  and  operators  the  actor  file 
provides  the  ability  to  define  the  latter  two  and  manipulate 
the  former.  Encased  between  the  actor  file's  linkage  and 
terminating  period  lies  the  only  area  where  blocks  exist, 
the  actor  file  body.  This  region  is  split  into  one  or  more 
definitions,  each  of  which  are  called  actors.  There  is  no 
upper  bound  on  the  number  of  actors  which  may  reside  in  a 
actor  file,  so  long  as  each  actor  is  properly  declared  in  a 
storage  file  which  is  linked  to  the  actor  file.  All  varia¬ 
bles  referenced  by  the  actors  must  also  be  predefined,  and 
declared.  Linking  may  be  postponed  until  entry  into  the 
block . 

Further  decomposition  of  the  actor  reveals  two  sec¬ 
tions,  the  operator  or  function  declaration,  and  the  block. 
Having  previously  discussed  the  block,  attention  will  now  be 
directed  on  the  declaration  section. 


The  operator  declaration  consists  of  the  operator  name, 
a  double  colon,  followed  by  the  keyword  "in".  Operators 
must  have  one  or  two  arguments  and  the  "in"  declares  the 
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input  argument  class  follows.  A  single  colon  separates  the 
class  from  the  declaration,  just  as  in  the  storage  file. 

The  difference  here  lies  in  that  a  maximum  of  two  declara¬ 
tions  are  allowed.  The  comma  between  them  appearing  where 
the  operator  would  in  an  expression.  Therefore  if  the 
operator  being  defined  is  a  unary  prefix  operator  the  first 
declaration  is  left  blank,  and  the  second  declaration  is 
preceded  by  a  comma.  In  a  like  manner  if  a  unary  suffix 
operator  is  defined  only  the  first  declaration  is  used;  the 
comma  and  the  second  declaration  are  left  blank.  All  binary 
operators  must  be  infix. 

Following  the  declaration  of  the  input  arguments  is  the 
like  action  for  the  operator's  single  output  argument. 
Initiated  by  the  keyword  "out"  it  declares  an  object  in  the 
same  manner  as  the  unary  suffix  operator  input,  a  class, 
single  colon,  and  declaration.  Both  the  input  and  output 
declarations  are  completed  by  a  line  terminator  symbol. 

The  second  type  of  actor  declaration,  that  for  func¬ 
tions,  is  similar  to  that  described  above,  but  since  func¬ 
tion  arguments  are  optional  differences  arise.  Again  the 
function  name  and  a  double  colon  start  the  decaration  off, 
and  may  be  followed  by  "in"  if  the  function  receives  a 
value.  If  a  value  is  received  the  declaration  is  that  used 
by  the  unary  suffix  operator  input.  This  may  appear  con¬ 
trary  since  function  names  procede  their  argument,  but  as  a 
maximum  of  one  is  possible  the  second  declaration  is  never 


III-19 


needed.  The  functions  output  or  return  declaration  is  iden¬ 
tical  to  the  operator  output,  except  when  ommitted  due  to  no 
return  value.  Therefore  a  function  without  arguments, 
either  way,  is  declared  simply  as:  f unction_name  ::  line 
terminator . 

After  the  operator  or  function  arguments  have  been 
declared  renaming  is  permitted  preceding  the  defining  block. 

A  line  terminator  symbol  follows  the  block  to  apply  the 
restriction  the  file  terminator,  or  period,  must  lie  on  a 
line  by  itself. 

Bundle  Files.  The  bundle  file  is  unique  in  its  func¬ 
tion,  differing  from  the  other  three  files  in  that  it  organ¬ 
izes  files  rather  than  manipulate  or  define  objects.  There¬ 
fore,  though  the  syntactic  structure  of  its  linkage  is 
identical  to  the  other  file's,  the  meaning  has  changed.  The 
share  and  copy  functions  provide  their  respective  actions 
globally  for  all  files  organized  by  the  bundle  file.  The 
rename  function  also  performs  its  assigned  task  throughout 
all  files  named  within  the  bundle's  body. 

The  body  of  a  bundle  file  is  simply  a  list  of  file 
names,  each  appearing  on  their  own  line.  These  names, 
organize  the  files  into  logical  packages.  Every  file  (bundle 
files  excluded)  must  be  declared  within  its  perceeding 
bundle  file  body,  or  an  error  is  generated. 

Input  and  Output 

D  like  many  of  primitive  high-level  languages  was  con- 
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structed  with  low-level  input  and  output  (I/O)  capabilities. 
D's  I/O  is  simply  the  assignment  of  a  value  to  a  location  in 
memory,  or  the  receiving  of  a  value  from  a  memory  location. 
The  specific  memory  address  is  actually  a  port  for  some 
device. 

Open,  Creat.  Close,  and  Unlink.  File  access,  on  the 
other  hand,  has  not  been  defined;  therefore,  it  will  be 
necessary  to  interface  with  the  Unix  operating  system.  To 
access  other  than  the  standard  files,  is  accomplished  with 
the  open,  close,  creat,  and  unlink  functions.  Open  and 
creat,  which  need  two  arguments  each,  will  take  a  structure 
as  there  argument.  The  structure's  components  are  a  file 
name,  or  an  array  of  characters  terminated  by  a  literal  zero 
bit  pattern,  and  an  integer.  This  structure  is  also  defined 
in  the  language  example  as  f ile_io_structure.  The  integer 
in  the  open  function  declares  access  as  read  only,  0,  write 
only,  1,  or  read  and  write,  2.  In  the  creat  function  the 
integer  declares  a  protection  mode  for  the  Unix  system. 
Protection  is  a  nine  bit  number  indicating  read,  write,  and 
execute  permissions  for  the  file  owner,  his/her  group,  and 
all  others  respectively  (6:162).  If  the  bit  is  set  it 
indicates  permission  is  granted;  a  common  protection  is  755 
octal  or  493  decimal.  For  example  a  bit  pattern  of 
111100001  gives  the  file  owner  full  permission  to  read, 
write,  or  execute  the  file.  Members  of  the  owners  group  may 
read  it  only,  and  all  others  may  execute  it  only,  open  and 
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creat  return  as  a  value  an  integer  in  the  range  of  3  to  15- 
25,  to  use  as  a  file  descriptor  for  subsequent  reading  or 
writing  to  that  file. 

The  inverse  function  of  open  and  creat  are  close  and 
unlink.  They  require  only  the  file  name,  as  a  string  of 
characters  terminated  by  a  literal  zero,  as  their  input 
argument.  Programs  may  have  a  maximum  of  15-25  files,  the 
number  varies  with  systems,  opened  at  any  particular  time; 
the  close  function  allows  the  file  descriptor  to  be  reused, 
while  leaving  the  file  intact.  Unlink,  on  the  other  hand, 
removes  the  file  from  the  system.  The  four  file  operation 
functions  all  return  as  values  either  a  non-zero  integer 
denoting  error  free  execution,  or  a  zero  if  an  error  occur¬ 
red.  These  functions  will  retain  their  Unix  names  and  be 
accessable  as  open(f  ile_io__structure) ,  creat  (f  ile_io_structure) , 
close(f ile_name) ,  and  unlink (file_name) .  A  more  detailed 
discussion  on  the  interface  to  the  Unix  system  is  available 
to  the  reader  in  Appendix  C.  Though  dealing  with  the  C 
language  it  will  further  expand  on  what  has  been  presented 
here,  and  may  provide  some  useful  higher  level  I/O 
functions. 

An  Example 

The  following  subsection  is  a  sample  D  program.  The 
method  in  which  it  is  presented  will  be  the  same  as  that 
used  in  reference  1.  The  numbers  and  colons  to  the  left  of 
the  page  are  not  part  of  the  language,  but  serve  to  identify 
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lines  for  explanation. 

The  object  of  the  program  is  to  read  a  given  number  of 
rational  numbers,  and  sort  them  using  a  binary  tree.  The 
assumption  is  made  that  the  function  get_number  exists,  but 
is  not  declared,  and  is  globally  shared  with  all  the  file 
present?  it  could  be  in  another  Unix  file  or  the  same  one. 
The  remainder  of  the  code  presented  resides  in  a  single  Unix 
file. 


***  code  segment  *** 

1  :  bundle  rational_sort 

2  :  structure_def initions 

3  :  io_struct_def 

4  :  variables 

5  :  mul_var 

6  :  build_tree 

7  s  . 

***  explanation  *** 

1  :  the  program  is  headed  by  a  bundle  file  named  rational_ 

sort. 

2  :  The  file  structure_def initions  is  declared  to  be  in 

rational_sort . 

3  :  The  file  io_struct_def  is  declared  to  be  in  rational_ 

sort. 

4  :  Ditto  for  variables. 

5  :  Ditto  for  mul_var. 

6  :  Ditto  for  build_tree. 

7  :  The  bundle  file  is  terminated. 

***  code  segment  *** 

1  :  state  structure_def initions 

2  :  rational  ::  {  int  :  numerator 

3  :  / 

4  :  int  :  denominator 

5  :  } 

6  :  complex  ::  {  rational  :  real_part,  imaginary_part 

7  :  } 

8  :  treenode  s  s  {  rational  :  number 
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VO  CO  -J  CT\  V/l  •U  U>  to 


treenode  :  fleft,  fright 


list_info  : s  {  treenode 
int 

} 


#  node 


state  io_struct_def 

share  structure_def initions 

io_structure  ::  {  int  :  f ile_descriptor 

char  :  buffer[512] 
int  :  n 

} 

f ile_io_structure  ::  {  char  :  f ile_name [20] 

int  :  mode 

} 


***  explanation  *** 

the  state  file  structure_def initions  is  initiated, 
the  structure  rational  is  defined  to  be  an  integer 
numerator , 
followed  by  a  ' /', 

followed  by  an  integer  named  denominator, 
the  definition  of  the  structure  rational  is  terminated, 
the  structure  complex  is  defined,  and  has  the  integer 
members  real_part,  and  imaginary  part, 
the  definition  of  the  structure  complex  is  terminated, 
treenode  is  composed  of  a  rational  number  named  number, 
followed  by  two  pointers,  left  and  right,  which  may 
point  to  an  object  of  the  class  treenode. 
now  defined  treenode,  like  rational  and  char,  becomes  a 
class 

list_info  is  a  structure  with  components  node,  a  poin¬ 
ter  to  a  treenode  structure, 
and  n,  an  integer. 

the  list_info  definition  is  terminated, 
the  state  file  is  terminated. 

***  code  segment  *** 

storage  variables 

share  structure_def initions 


rational 

treenode 

list_info 

int 

null 


number,  get_number  null 

froot  ■  null 

info 

>  int,  >  rational,  *  int, 
main_routine  int, 
put_in_list  list_info 
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10 

11 

12 


storage  mul_var 
int  s  sign  =  0 


***  explanation  *** 

1  :  the  storage  file  variables  is  initiated. 

2  :  linkage  is  made  to  the  classes  in  structure_def initions 

3  :  the  variable  number  is  declared  to  be  of  class  ratio¬ 

nal,  and  the  function  get_number  is  declared  to  return 
a  rational  result  and  receive  no  inputs. 

4  :  root  is  declared  to  be  a  pointer  to  the  class  treenode, 

and  is  given  an  initial  value  of  null. 

5  :  info  is  declared  to  be  of  type  list_info. 

6  :  the  operator  '>'  is  declared  to  return  and  integer  and 

accept  integer  arguments,  there  is  also  an  operator, 
•>',  which  returns  an  integer,  but  it  accepts  rational 
arguments.  The  operators  and  '■*'  both  accept  and 
return  integer  arguments 

7  :  main_routine  and  put_in_list  are  declared  as  functions 

which  do  not  return  values,  but  do  require  arguments  of 
the  classes 

8  s  int  and  list_info  respectively.  Note  that  although  the 

comma  following  main_routine  is  a  name  delimiter,  it 
can  function  in  the  dual  role  of  a  line  continuation 
character  also. 

9  :  the  storage  file  variables  is  terminated. 

10:  the  storage  file  mul_var  is  initiated. 

11:  an  integer  variable,  sign,  is  declared,  and  initiated 

to  zero. 

12:  the  storage  file  mul_var  is  terminated. 

***  code  segment  *** 

1  :  actor  build_tree 

2  :  share  structure_def initions , 

3  :  variables 


***  explanation  *** 

1  :  the  actor  file  build_tree  is  initiated. 

2  :  linkage  is  connected  to  structure_def initions, 

3  :  and  variables.  Remember  it  is  assumed  that  get_number 

is  defined  and  shared 

***  code  segment  *** 

4  :  main_routine  : :  in  integer  :  count 

5  :  {  count  >  0  $  number  =  getnumber 

6  :  0  $  info'node  »  root 

7  :  0  $  info'n  =  number 

8  :  0  $  put_in_list  info  \ 
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W  K>  M  O 


*** 


explanation 


*** 


:  an  actor  function  is  defined  under  the  name  main_ 

routine;  it  receives  as  input  an  integer,  and  gives  it 
the  local  name  count. 

3  :  the  defining  block  is  opened  by  '  the  expression 
following  is  a  guard  because  it  is  followed  by  a 
If  the  expression,  once  evaluated,  is  greater  then  zero 
the  statement  after  the  •$'  is  executed.  Control  pas¬ 
ses  to  line  10  in  order  to  evaluate  the  expression. 
Following  the  statement  is  the  line  continuation  char¬ 
acter  <blank>  indicating  the  next  statement  „ill  be 
executed  even  though  the  guard  is  closed.  If 
'count  >  O'  is  evaluated  non-positive  the  block  will  be 
terminated  since  all  other  statements  in  the  block  are 
closed. 

5  :  the  node  component  of  the  variable  info  is  assigned  the 
same  value  as  root.  Execution  of  this  statement  may 
only  take  place  if  the  preceding  statement  is  executed. 

7  :  the  n  component  of  info  is  assigned  the  same  value  as 
number . 

B  :  the  function  put_in_list  is  called  with  info  as  its 
argument. 

9  :  the  defining  block  of  main_routine  is  terminated. 

***  code  segment  *** 

>  : :  in  int  :  inti,  int2 
out  int  :  true 
{  inti  -  int2  $  return  1 

return  0 

L4 :  } 

***  explanation  *** 

L0:  the  operator  *>'  is  to  be  defined;  its  input  arguments 

LI:  are  integers,  and  its  output  argument  is  an  integer. 

L2:  the  defining  block  is  opened  an  the  expression  inti  - 
int2  is  evaluated.  If  the  result  is  positive  the 
operator  will  execute  the  following  statement  and  re¬ 
turn  a  value  of  one.  The  return  also  terminates  the 
action  by  giving  control  to  the  calling  actor. 

L3:  if  the  expression  in  12  is  negative  or  false  a  zero  is 

the  return  value. 

L4:  the  defining  block  is  closed. 

***  code  segment  *** 

L5:  put_in_list  ::  in  list_info  :  info 

16:  rename  info'*node  pnode 
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17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 


15: 


17: 

18: 

19: 


20: 


21: 

22: 

23: 


24: 


25: 

26: 

27: 

28: 


rename  inf o' node  node 
rename  info'n  n 
null 

{  node  $  {  new  node; 

pnode' number  =  n; 
pnode'left  =  pnode' right  =  null 
}  .. 

{  n  >  pnode'number  $  {  node  =  pnode 'right 

put_in_list  info 
}  .. 
node, 

=  pnode'left 
put_in_list  info 


***  explanation  *** 

the  function  put_in_list  is  identified  as  receiving  an 

argument  of  type  info_list,  named  info. 

the  local  variable  info  is  has  one  of  its  components 

renamed  so  info'#node  can  be  referenced  by  pnode 

the  local  variable  info  is  renamed  so  its  components 

are  accessable  as  node 

and  n. 

the  expression  'null'  precedes  the  defining  block 
therefore  for  a  guard  to  be  declared  as  open  it  must 
evaluate  to  null. 

the  defining  block  is  opened  and  the  value  of  node  is 
determined;  if  it  is  null,  then  execution  continues 
with  the  opening  of  the  unnamed  block  following  the 
'$',  and  an  object  of  the  type  node  points  to  is 
dynamically  created,  node  receives  the  location  of  the 
created  object  as  its  value.  Otherwise  control  passes 
to  line  23. 

the  component  number  of  node  is  assigned  the  n's  value, 
the  left  and  right  pointers  of  node  are  assigned  null, 
the  current  block  is  terminated  and  as  a  statement  its 
line  continuation  character  directs  the  program  to 
terminate  the  current  block,  which  now  is  the  defining 
block . 

an  unlabled,  unguarded  block  is  opened  and  the  follow¬ 
ing  expression  is  a  guard.  If  evaluated  non-positive 
control  passes  to  line  27,  otherwise  another  block  is 
opened,  and  node  is  assigned  the  right  child  of  inode, 
the  function  put_in_list  is  recursively  called  with 
info  as  its  argument. 

the  unlabled  block  is  terminated,  and  the  current  block 
is  terminated,  by  the  causing  control  to  pass  to 

line  31. 

node  is  assigned  the  left  child  of  inode. 

the  comma  was  used  to  continue  the  line  starting  on 
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line  27. 

the  function  put_in_list  is  recursively  called  with 

info  as  its  argument. 

the  current  block  is  terminated. 

the  defining  block  is  terminated. 

***  code  segment  *** 

>  : :  in  rational  :  rati,  rat2 
out  int  :  true 

rename  rati 1  numerator  nl 
rename  rati 'denominator  dl 
rename  rat2 'numerator  n2 
rename  rat2 'denominator  d2 
{  nl*d2-n2*dl  $  return  1 

return  0 

} 


***  explanation  *** 

the  definition  of  '>'  for  rationals  is  initiated, 
it  returns  an  integer  result, 
the  component  rati 'numerator  is  renamed  to  nl 
the  other  components  are  renamed  in  a  like  manner 
the  defining  block  is  opened,  and  the  expression 
nl*d2-n2*dl  is  evaluated;  if  positive  the  actor  termin¬ 
ates  by  returning  a  value  of  one. 

Otherwise  it  terminates  by  returning  a  value  of  zero, 
the  defining  block  ends. 

***  code  segment  *** 

*  : :  in  int  ;  inti,  int2 
out  int  :  product  =  0 
{  copy  mul_var 
{  inti  ==  0  $  . . 
int2  ==  0  $  . . 

product  =  product  +  inti; 
int2  >0  $  int2  =  int2  -  1  \ 

int2  =  int2  +  1; 
sign  =  1  \ 

} 

sign  $  product  «  0  -  product 

} 


***  explanation  *** 

the  integer  multiplier  operator's  definition  is 
started . 

it  returns  an  integer  which  is  initialized  to  zero, 
the  defining  block  is  opened  and  linkage  is  extended  to 
the  storage  file  mul_var.  The  variable  sign  still  has 


III-28 


its  initialized  value  because  the  copy  function  pre¬ 
serves  it.  The  share  function  will  do  the  same,  but 
only  if  the  variable  has  not  been  previously  modified. 

41:  an  unlabled  block  is  opened  and  inti  is  checked  to  see 

if  it  equals  zero.  This  is  accomplished  by  passing 
control  to  the  '=='  operator.  If  inti  is  zero  the 
current  block  terminates. 

42:  int2  is  checked  in  the  same  manner,  also  causing  block 
termination  if  zero. 

43:  product  is  incremented,  or  decremented  by  inti. 

44:  if  int2  is  greater  than  zero  it  is  decremented,  and  the 
current  block  is  reexecuted. 

45:  otherwise  int2  is  incremented, 

46:  sign  is  assigned  the  value  of  one,  and  the  current 

block  is  reentered. 

47:  the  current  block  is  terminated. 

48:  if  sign  is  positive  the  product's  sign  is  changed. 

49:  the  defining  block  is  terminated. 

***  code  segment  *** 

50:  ■«  : :  in  int  :  inti,  int2 

51:  out  int  :  true 

52:  {  inti  -  int2  $  return  0 

53:  int2  -  inti  $  return  0 

54:  return  1 

55:  } 


***  explanation  *** 

50:  the  '=='  operator  is  initiated,  and  declared  to  require 

integer  arguments. 

51:  an  integer  result  is  returned. 

52:  the  defining  block  is  opened  and  inti  -  int2  is  eval¬ 

uated;  if  the  result  is  positive  the  actor  terminates 
by  returning  zero. 

53:  otherwise  int2  -  inti  is  evaluated.  Again  if  positive 
the  actor  terminates  by  returning  zero. 

54:  otherwise  a  one  is  returned,  terminating  the  actor. 

55:  the  defining  block  is  terminated. 

This  program  does  not  attempt  to  demonstrate  the  entire 

D  language,  but  it  is  included  as  means  whereby  the  reader 

may  gain  a  greater  understanding  of  D. 
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I Y  The  Design 


Design  is  a  human  activity  that  has  eluded  definition 
for  some  time  (7:23),  partly  because  in  every  problem  deci¬ 
sions  are  made  which  are  based  on  the  engineer's  subjective 
feelings.  Software  design  is  further  complicated  by  perso¬ 
nal  opinion  as  to  what  the  best  means  for  the  problem  solu¬ 
tion  is.  Design  possibilities  may  be  as  varied  as  the 
solution  space  permits,  forcing  evaluation  criteria  to  be 
politically  motivated.  Software  design  quality  can  no  lon¬ 
ger  then  be  termed  as  right  or  wrong,  but  must  be  thought  of 
as  a  continuum  from  good  through  fair,  poor,  and  bad  (7:23). 

Though  design  cannot  be  formalized  into  a  step  by  step 
process  yeilding  a  singular  result;  the  engineer  is  not 
excused  from  using  tried  design  techniques  to  ensure  the 
final  product  occupies  the  highest  level  of  the  quality 
continuum.  There  exist  a  plethera  of  methods  to  act  as  a 
basis  for  the  solution.  These  may  be  classified  into  four 
basic  catagories:  1)  top-down  structured  design,  2)  data- 
structure  design,  3)  Parnas  decomposition  criteria,  and  4) 
object-oriented  design  (1:32).  No  one  method  can  be  singled 
out  as  the  best  for  all  circumstances.  Each  of  these 
methods  have  their  respective  problem  sets  for  which  they 
were  defined.  For  example,  the  data-structure  design  tech¬ 
nique  imparts  a  fine  detail  to  program  objects,  observes 
their  interrelationships,  and  then  forms  the  program  struc¬ 
ture  from  these  relationships  (7:152).  Such  a  technique 


works  well  for  COBOL  applications  where  operations  take  a 
back  seat  to  data  elements.  Top-down  design,  on  the  other 
hand,  resides  at  the  other  end  of  the  spectrum  placing  the 
emphasis  on  operations,  increasing  the  likelihood  of  a  func¬ 
tional  solution,  at  the  expense  of  the  data  structures. 

While  both  the  Parnas  method  and  object-oriented  design 
achieve  a  healthy  balance  of  actors  (operations),  and  ob¬ 
jects.  These  two  methods  appeared  flawed  in  that  they  don't 
lead  to  a  clear,  logical  orientation  of  the  program  struc¬ 
ture.  A  better  design  method,  and  the  one  to  be  used  for 
this  system,  will  be  a  combination  of  the  top-down  and 
object-oriented  designs.  This  method  will  yield  a  greater 
degree  of  flexibility  for  data  element  construction,  while 
decomposing  the  system  functionally;  thereby  allowing  it  to 
be  modled  after  the  D  language  structure. 

During  design  one  attempts  to  model  the  problem  into 
some  software  representable  abstraction,  which  will  permit 
an  algorithm(s)  (the  implementation)  to  manipulate  the  input 
into  meaningful,  human  interpretable  form,  or  that  which 
another  program  will  understand.  This  modeling  seeks  to 
match  the  structure  of  the  problem  into  logical  units. 

These  units  have  two  types;  the  passive  types  are  objects 
(or  nouns);  they  are  acted  upon  by  the  second  type  called 
operators  (or  verbs).  The  r.ouns  are  instantiated  as  typed 
constructs  according  to  the  implementation  language's  rules. 
If  these  rules  are  weak,  as  in  FORTRAN,  further  abstraction 
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by  the  engineer  is  demanded.  Meanwhile  the  verbs  become 
modules,  or  subprograms  of  the  set  language. 

Until  now  the  process  described  is  the  initial  steps 
taken  in  object-oriented  design.  Top-down  design  is  intro¬ 
duced  by  functionally  decomposing  the  modules  into  succes- 
sivly  less  complicated  operations.  This  breaking  apart  of 
modules  continues  recursively  until  every  resulting  module 
is  either  simple  enough  to  code,  or  its  further  decomposi¬ 
tion  is  implementation  dependent.  The  object-oriented 
analysis  of  nouns  and  verbs  is  repeated  at  each  level  of 
decomposition. 

The  method  used  to  pictorially  show  the  structure  of 
the  design  will  be  structure  charts.  This  method  was  chosen 
for  its  readability,  simplicity,  and  ease  of  documentation. 


a)  Module  Call  Notation 


Simple  description  of  what  the 
module  does 

Symbol  for  a  module  (the  box) 


—Indicates  that  module  1.0  calls 
module  1.2  (with  an  eventual 
-  return  of  control  to  module  1.0) 


1.1 


1 . 2i 


b)  Module  Couple  Notation 


O— * 

Indicates  data 
couple 


jGet 

'Edited 

Transaction. 


Indicates  control 
couple  (flag) 


Read 

Transaction 


Figure  1;  Structure  Chart  Notation  (5:61) 

In  addition,  the  following  will  be  used  to  show  control 
sequencing: 


a)  ilteration 


Figure  2:  Structure  Chart  Control  Sequencing 
The  initial  design  problem  is  to  interpret  a  D  program. 


Since  the  input  form  is  already  predefined,  and  the  output 
must  be  a  C  program  file,  for  the  C  compiler,  the  the  global 


data  input  and  output  have  been  set.  The  system  at  its 
highest  level  then  has  the  following  structure. 


jlnterpret 

I  D  File 

1 _ _ 


Notes: 

1:  D  Program  File 
2:  C  Program  File 


Figure  3:  Global  Design 

To  implement  this  design  with  code  would  be  ludicrous; 
hence  a  further  dividing  of  "Interpret  D  File"  is  needed. 
This  decomposition,  which  will  generate  more  data  elements 
and  procedures,  must  address  the  question:  along  what  lines 
will  the  decomposition  proceed?  Experience  provides  guide¬ 
lines  for  a  distinction  between  the  lexical  analysis  and  the 
actual  language  interpretation. 


Xb£  Lexical  Analyzer 


The  lexical  analyzer  returns  units,  called  tokens, 
along  with  their  additional  characteristics.  From  this 
description  a  module  called  get_token  is  perceived  which 
will  return  an  object  of  type  token.  Tokens  will  then  be 
provided  to  the  interpreter,  forming  the  structure  in  figure  5. 


Interpret 
D  File 


Get_token 

_ i 


Notes: 

1:  D  Program  File 
2:  Token 

3:  C  Program  File 


Figure  4:  The  Addition  of  Get_token 


Now  a  token  has  the  following  properties:  1)  its  name  - 
the  literal  string  of  characters  which  form  it,  2)  its  type 

-  the  lexical  class  to  which  it  belongs,  and  3)  its  position 

-  the  line  number  it  occupies  in  the  program  file.  It  is 
possible  to  implement  a  greater  detail  for  the  third  charac¬ 
teristic,  i.e.  by  supplying  the  token's  position  on  said 
line,  though  this  increased  detail  is  rarely  needed. 

Get_token  is  still  to  complicated  to  code;  therefore  an 
orderderd  fracturing  of  it  becomes  necessary.  Since  the 
module  is  dealing  with  tokens,  the  logical  choice  would  be 
to  split  it  along  one  of  the  token  characteristics.  A  split 
depending  on  naming  would  be  impossible,  because  the  possi¬ 
ble  combinations  of  names  would  exceed  the  computer's  memory 
limitations.  In  a  like  manner,  keying  on  the  token's  line 
number  provides  little  information,  and  varies  widely. 

Hence  the  decomposition  of  Get_token  should  key  on  the 
classes  of  tokens. 

D  tokens  will  be  catagorized  into  seven  types:  literal 
names,  integers,  identifier  names,  keywords,  punctuation 
symbols,  operator  symbols,  and  comments.  This  disection 
disagrees  with  Jennings  view  of  five  token  types:  symbols, 
names,  quoted  literals,  integers,  and  comments  (5:46),  yet 
no  contridiction  exists.  The  former  list  merely  expands  on 
naming,  and  symbols,  while  reguarding  quoted  literals  as 
expressions  (5:55)  to  be  handled  by  the  interpreter. 

Figure  5  shows  the  final  structure  of  Get_token.  Note,  an 
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implementation  dependent  module,  get_character,  has  beed  added  to 


"read"  the  D  program  file. 

f 

i  1  Notes: 

— _ — ,  1:  token 


j  Get  2:  character 

Token 


The  lnt££pietei 

The  interpreter,  like  Get__token,  must  also  be  broken 
down  into  smaller  units.  Unlike  Get_token,  a  break  along 
lexical  classes  would  only  produce  confusion.  The  interpre¬ 
ter  deals  with  another  well  defined  structure  though,  that 
is  the  D  program  input.  The  input's  consistency  lies  in 
that  it  must  correspond  to  established  syntax  rules.  Though 
the  interpreter  must  maintain  flexibility  for  input  contain¬ 
ing  minor  aberations  from  D's  structure,  i.e.  provide  syntax 
error  recovery,  it  basically  receives  D  structured  code. 

In  addition,  the  parsing  of  the  program,  the  interpre¬ 
ter's  first  major  function,  should  provide  nearly  all  of  the 
control  sequencing,  as  the  systems  actions  are  contingent 
upon  the  D  program.  Hence  the  system  structure  should  be 


modeled  after  O's. 


Wirth  presents  a  method  for  moving  directly  from  a 
deterministic  syntax  graph  to  a  parser  (10:291).  While  this 
technique  is  an  integral  part  of  the  following  design,  it 
cannot  be  fully  implemented,  because  D  fails  the  second  of 
two  restrictions  imposed  on  the  graph.  Specifically,  all 
first  symbols  following  a  null  path  must  be  disjoint  from 
the  first  symbols  which  are  alternatives  to  the  null  path. 
Furthermore  a  formal  root,  or  goal,  was  not  part  of  Capt. 
Jennings  language;  although  it  is  intuitively  grasped  that 
the  D  files  should  be  grouped  into  conventional  program 
files. 

Interpret 

The  module  Interpret  will  be  the  driver  of  the  inter¬ 
preter.  Its  function  will  be  to  initialize  all  externals 
necessary  through  function  calls.  These  pre-interpret  func¬ 
tions  are  Unix  file  set  up,  the  writing  of  D's  run  time 
environment  to  the  appropriate  file,  variable  initializa¬ 
tion,  and  structure  initialization. 

Furthermore,  since  the  D  files  are  not  syntactically 
connected  (rather  there  connection  is  logical  through  the 
linkage  construction),  it  is  the  responsibility  of  Interpret 
to  control  their  calling.  The  files,  maintained  as  a  list 
or  tree,  have  certain  properties.  These  properties  will  be 
grouped  by  the  C  structure,  and  are: 

*  name  -  the  file  name  following  the  file  type  keyword 


*  type  -  bundle,  state,  storage,  or  actor 

*  code  -  another  structure  holding  the  C  code  generated 

by  the  file's  body 

*  vdef  -  variables  (classes)  defined;  a  state  file 

function 

*  vdec  -  variables  declared  (instantiated);  a  storage 

file  function 

*  fodef  -  functions  or  operators  defined;  an  actor  file 

function 

*  fodec  -  functions  or  operators  declared;  a  storage 

file  function 

*  rtree  -  a  tree  containing  all  the  renaming  actions 

taken 

*  next  (or  left  &  right)  -  pointer(s)  to  the  next 

record 

The  flow  of  control  for  Interpret  will  be  to  determine 
the  file  type  by  its  keyword,  perform  linkage  with  the 
Linkage  module,  then  call  the  appropriate  file  body  module 
to  interpret  the  file.  This  sequence  will  iterate  until  all 
files  have  been  translated.  The  arguments  passed  to  the 
file  body  modules  are  the  D  program  file  pointer  (dptr),  the 
C  program  file  pointer  (cptr),  and  the  root  of  the  file 
record  structure.  Linkage  will  receive  the  same  minus  cptr. 


Linkage 

The  module  Linkage  proceeds  the  call  to  each  file  body. 
Linkage  is  partially  generic  in  that  it  will  process  the 
linkage  of  all  four  files,  as  well  as  the  renaming  following 
function  or  operator  declarations,  and  the  linking  of  varia¬ 
bles  inside  blocks.  Though  it  needs  to  be  told  which  of  the 
above  situations  it  is  in,  because  the  restart  patterns,  in 
the  event  of  an  error,  are  different  for  each  case.  Linkage 
will  not  generate  code,  as  C  contains  no  equivelent  struc¬ 
ture,  but  will  manipulate  the  file  records  recording  file 


relationships.  For  example,  a  share  operation  from  a  state 
file  to  a  storage  file  will  cause  a  duplication  of  the  state 
file's  vdef  list  to  be  placed  on  the  storage  file's  vdef 
list . 

Linkage's  decomposition  then  consists  of  an  iteration 
over  three  modules  Share,  Copy,  and  Rename,  each  of  which 
will  receive  the  variables  dptr,  root,  and  file_type.  The 
first  two  will  call  functions  to  duplicate  and  move  the  file 
record's  list,  while  the  latter  will  access  a  function  to 
add  name  pairs  to  the  rtree  node.  Rename  must  also  access  a 
module  which  will  parse  a  logical  name  as  one  of  the  named 
pairs.  Discussion  on  this  module  will  be  deferred  until 
later. 

1h&  Bundle  File  Body 

The  bundle  file  body,  module  Bundle,  is  very  simple. 

Its  task  is  to  read  a  list  of  file  names  from  input,  and 
place  those  names  into  the  ordered  structure  which  contains 
the  file  records.  The  algorithm  involved  is:  while  a  name 
is  read  put  it  in  the  file  structure  end  while.  Throughout 
the  interpreter  much  list  activity  takes  place  with  differ¬ 
ent  objects.  The  algorithms  involved  for  placement  and 
retrieval  will  be  the  same  reguardless  of  what  objects  are 
being  manipulated.  Therefore,  whenever  a  function  is  refer¬ 
enced  to  operate  on  a  list  it  is  assumed  the  reader  is 
sufficiently  versed  in  linked  list  and  tree  walking  tech¬ 
niques  to  omit  further  detail. 


lilfi.  State  Ella  Body 

The  state  file  body  is  considerably  more  complicated. 

A  state  file  defines  two  types  of  classes  the  scalar,  and 
the  structure.  It  will  iterate  over  these  two  calls  to 
functions  until  a  file  keyword  or  terminating  period  is 
found. 

The  structure  differs  from  the  scalar  following  the 
receipt  of  a  token  named  If  a  is  next  the  module 

Structure  will  be  called,  and  if  an  integer  or  integer 
expression  is  detected  Scalar  is  called,  otherwise  an  error 
is  generated.  Scalar  and  Structure  are  passed  dptr,  so  they 
may  in  turn  pass  it  to  Get_  token.  Both  also  contain  suf¬ 
ficient  arguments  discussed  below  to  return  all  the  neces¬ 
sary  information  gleaned  from  the  parsed  code.  State  then 
places  that  information  into  yet  another  data  structure  to 
be  added  to  the  state  file's  vdef  list. 

This  new  structure,  called  an  sosnode  (for  state  or 
structure  node),  has  the  following  elements:  the  class' 
name,  its  members  (another  structure),  a  lower  bound,  an 
upper  bound,  and  appropriate  pointer (s)  to  the  next  sosnode. 

Members  will  be  a  linked  list  of  character  arrays  which 
hold  the  names  of  the  structures  members.  Members,  along 
with  "code1',  a  variable  if  like  structure,  will  be  passed  to 
Structure,  while  lower  bound  and  upper  bound  will  be  passed 
to  Scalar.  Both  modules  are  also  sent  an  error  flag,  which 
if  set  upon  return  indicates  an  error  occured  during  the 
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definition.  If  error  is  not  set  the  structure  or  scalar  is 


added  to  the  vdef  list.  Note,  it  is  possible  to  distinguish 
between  the  two  types  after  the  definition.  If  the  type  is 
a  scalar,  then  members  equals  null,  otherwise  lower  and 
upper  bound  are  both  null. 

Scalar  Definition 

Scalar  has  a  simple  sequential  flow.  It  looks  for  two 
integers  or  integer  expressions  separated  by  Integer 

expressions  are  handled  by  the  module  Expression,  whose 
discussion  is  more  appropriate  later. 

Structure  Definition 

Structure,  like  State,  is  also  split  into  an  iterative 
process  over  two  choices  object  declarations  and  symbol 
strings.  Object  declarations  may  be  recognized  as  the  first 
token  of  them  is  a  predefined  or  user  defined  class.  In 
this  case  control  passes  to  Object_Declaration,  along  with 
all  the  arguments  Structure  received  to  be  completed. 
Object_declaration  also  receives  the  name  of  the  structure 
being  defined,  and  the  file  type  STATE.  The  former  is 
needed  so  the  function  Is_Class  can  recognize  the  current 
structure  as  such  and  allow  appropriate  pointers  to  be 
defined.  The  file  type  permits  Object_Declaration  and  its 
sub-modules  to  adjust  to  minor  semantic  differences  between 
a  state  and  storage  object  declaration  (e.g.  initialization 
is  not  permitted  in  the  state  case). 


If  a  recognizable  class  is  not  seen,  then  the  rest  of 
the  program  line  will  be  parsed,  and  the  token  names  will  be 


concatenated  to  form  an  addition  to  members. 

Object  Declaration 

Object_Declaration's  main  purpose  is  to  verify  receipt 
of  a  valid  class  with  Is_Class.  The  construction  '$logical 
name'  may  also  provide  a  valid  class.  If  the  class  abstrac¬ 
tion  operator,  is  seen  Logical_Name  will  be  called  to 

return  the  logical  name  following  the  '$'.  Further  discus¬ 
sion  of  Object_Declaration  is  delayed  until  Logical_Name  is 
defined. 

Logical  Name 

Logical_Name  receives  the  dptr,  an  empty  array  (unless 
this  is  a  recursive  call),  and  the  structure  code  discussed 
earlier.  It  proceed  with  an  algorithm,  generated  by  the 
language's  syntax,  to  parse  a  logical  name  concatenating  the 
tokens  it  receives  onto  the  array.  Logical  name  performs 
all  the  necessary  conversions  to  proper  C  code,  with  the 
exception  of  array  subscripts,  A  call  to  Expression  fills 
code  with  the  correct  C  syntax.  The  logical  name  in  its 
interpreted  form,  along  with  the  subscript  translation  are 
passed  back  to  the  calling  module. 


the  array  in  a  similar  manner,  and  compares  the  members  of 
the  name  to  defined  structures.  Class  (the  function)  will 
return  the  class  of  the  logical  name,  if  one  exists,  and  a 
value  indicating  the  following  conditions: 

*  0  -  the  array  is  a  valid,  defined  logical  name 

(class=class) 

*  1  -  the  logical  name  is  not  defined  (class=null) 

*  2  -  the  logical  name  contains  a  member  which  is  not 

defined  (class=the  undefined  member) 

If  no  errors  occur  Object_Declaration  makes  repeated 
calls  to  Declarator,  so  long  as  each  successful  parse  of 
Declarator  is  followed  by  the  token  After  normal 

termination  of  the  Declarator  calls,  Object_Declaration 
returns  to  whomever  called  it  (Structure  or  Storage)  with 
the  appropriate  data  areas,  code  and  members,  filled  in.  If 
an  error  occurs  Ob ject_Declaration  will  still  return,  but 
code  and  members  will  be  incomplete,  and  will  be  rejected  by 
the  calling  routine. 

Pfi-claiator 

Declarator  parses  and  codes  the  declaration  of  one 
object  including  the  optional  initialization.  Members, 
passed  to  Declarator  by  Ob ject_Declaration,  is  filled  in 
completely  at  this  level.  Code  may  also  be  completed,  if 
initialization  or  array  subscripting  does  not  occur.  Should 
such  take  place  code  is  shipped  off  the  Expression  for 
completion.  The  file  type,  as  mentioned  above,  is  propa¬ 
gated  to  this  level;  hence,  if  a  variable  is  initialized, 
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and  the  file  type  is  STATE  an  error  is  generated. 

Other  arguments  received  by  Declarator  include  dptr, 
the  current  structure  being  defined  (if  the  route  to  this 
module  was  through  Structure)/  and  root.  Though  not  used  by 
this  routine,  root  is  needed  by  Expression,  while  the  cur¬ 
rent  structure  is  needed  by  the  function  Is_Class.  Is_Class 
will  be  used  in  Declarator  to  determine  when  functions  are 
being  defined,  as  the  usual  indicator,  a  token  '(',  is  not 
present  in  D. 

Exp.ressi.on 

Expression  is  the  crux  of  the  interpreter's  code  gener¬ 
ation.  Though  it  is  only  one  out  of  the  twenty-nine  parsing 
modules  it  will  create  over  half  the  code.  Three  of  the 
four  file  types  depend  on  Expression,  yet  its  decomposition 
is  basically  a  multiple  if-elseif-else  statement  inside  a 
while  loop.  Expression  receives  dptr,  root,  and  code  as  its 
arguments,  which  it  passes  some  or  all  to  its  worker 
modules . 

Each  of  these  workers  is  a  different  form  of  an  expres¬ 
sion,  and  will  fill  in  the  appropriate  C  code.  Three  of  the 
six,  namely  Logical_Name,  Func_or_Op_Name,  and  Parenthesis, 
call  Expression  recursively.  The  other  three  are  Single_ 
Quoted_X.iteral,  Double_Qouted_Diteral,  and  Accept.  The  most 
complicated  of  the  six,  Logical_Name,  has  already  been  dis¬ 
cussed.  The  *est  are  simple  enough  to  transfer  directly 
into  code;  again  their  function  is  to  parse  and  generate  the 
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code  for  the  respective  expression  type  their  name  implies. 

Storage 

Moving  back  to  the  file  level  the  next  routine  to  be 
discussed  is  Storage.  Storage  is  called  by  Interpret  with 
the  same  arguments  as  State,  namely  cptr,  dptr,  and  root. 

Its  function  is  next  to  bundles  in  simplicity,  while  its 
data  structures  are  the  most  complicated  after  the  file 
record. 

Storage  consists  of  multiple  iterations  of  Object_ 
Declaration  until  the  file's  terminating  period,  or  a  file 
keyword  is  detected.  Since  Object_Declaration  handles  all 
error  conditions  Storage  need  only  accept  or  reject  the 
values  returned  depending  on  the  condition  of  the  error 
flag.  If  accepted  the  structure  members  is  attacked  by  the 
function  Find_Member  which  extracts  the  information  recorded 
about  one  variable,  function,  or  operator.  The  declared 
object  is  then  added  to  the  appropriate  declaration  list. 
Find_member  is  repeatedly  called  until  all  declared  objects 
have  been  removed  from  the  members  structure. 

Two  types  of  declaration  lists  are  part  of  the  file 
record.  The  vdec  list  organizes  declared  variables,  while 
the  fodec  list  handles  functions  and  operators.  Vdec  has 
the  following  composition:  a  name,  a  type  (or  class),  two 
integers,  and  a  pointer(s)  to  the  next  record  in  the  list 
(tree).  The  integers  in  vdec  are  used  to  annotate  the  level 
of  indirection  of  the  variable;  i.e.  it  is  a  count  of  the 
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number  of  pointer  references  must  proceed  it  to  get  the 
objects  value.  The  second  integer  indicates  the  dimention- 
ality  of  the  variable,  whether  it  is  a  scalar  (value  =  0), 
an  array  (value  =  1),  a  matrix  (value  =  2),  etc.  The  names 
of  these  integer  locations  are  pointer  and  array 
respectively. 

Tne  fodec  (and  fodef  which  is  identical)  structure  is 
suited  to  the  possible  attributes  a  function  may  have  namely 
the  function  or  operator  name,  its  input  type,  its  output 
type,  three  structures  of  type  vdec,  a  renaming  tree,  and 
appropriate  pointers  to  the  next  structures. 

The  three  vdec  structures  hold  information  on  the  func¬ 
tion  or  operators  arguments,  and  results.  These  may  contain 
null  values  as  arguments  and  results  are  not  always  re¬ 
quired.  It  is  admitted  that  the  input  and  output  types  are 
not  needed  as  this  information  would  also  be  carried  in  the 
vdec  structures;  however,  they  are  added  to  facilitate  the 
module  Expression  in  its  type  checking.  While  the  rename 
tree  is  needed  for  the  local  remaning  of  objects  within  a 
function's  or  operator's  scope. 

The  functions  which  add  the  declared  objects  to  their  re¬ 
spective  lists  are  patterned  in  the  same  manner  as  those  used  in 
manipulating  the  file  structure,  and  the  vedf  (variables  defined) 
structure . 

Actor 

The  final  subgroup  of  modules  under  Interpret  to  be 
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discussed  are  those  whose  functions  are  needed  to  parse  and 
code  the  actor  file.  The  routine  which  controls  the  se¬ 
quencing  is  Actor.  Actor  is  responsible  for  an  iterative 
calling  of  either  Function_Declaration  or  Operator_Declara- 
tion,  Linkage,  and  Block,  in  the  named  order.  Its  other 
responsibilities  include  writing  the  code  produced  by  the 
declaration  routines,  and  producing  the  C  function  shell: 

func_type  f unc_name (argument_list) 
argument_declaration; 

{  variables?  /*  provided  by  the  share  or  copy  */ 

C  code  /*  produced  by  Block  */ 

}  /*  ending  right  brace  */ 

Function  Declaration 

Function_Declaration  controls  the  calls  to  Declarator 
as  it  sees  the  keywords  in  and  out.  The  receipt  of  the 
keywords  is  not  actually  necessary  as  the  system  is  already 
aware  of  the  types  of  the  arguments  and  results  through  the 
information  received  in  the  storage  file,  wherein  the  func¬ 
tion  or  operator  was  declared.  The  program  will  key  on 
these  special  tokens  (in  and  out)  though  in  order  to  main¬ 
tain  consistency  with  the  rest  of  the  system. 

Declarator  will  be  called  in  the  same  manner  as  Object_ 
Declaration  called  it.  The  difference  lies  in  that  Function 
Declaration  will  not  iterate  over  the  call. 

Function_Declaration  will  also  handle  the  placing  of 
the  locally  declared  input  variable's  information  into  the 
functions  fodef.argl  node.  The  fodef  node  has  the  same 


structure  as  the  fodec  node  defined  under  the  subsection 


Storage.  In  addition,  the  functions  result  will,  in  a  like 
manner,  be  placed  in  fodef. result.  Note  that  the  routine 
Find_Member  will  be  utilized,  as  it  was  under  the  control  of 
Storage,  to  accomplish  these  tasks. 

Operator  Declaration 

Operator_Declaration  accomplishes  the  same  process  that 
Function_Declaration  does.  Its  difference  lies  in  that  it 
must  be  able  to  handle  the  addition  of  another  input  varia¬ 
ble.  Following  the  syntax  of  D  a  minimum  of  two  calls  to 
Declarator  must  take  place  (minimum  of  one  for  in,  and  one 
for  out).  Like  its  counterpart  for  functions  Operator_ 
Declaration  will  set  the  vdec  nodes  in  fodef,  and  will 
return  the  appropriate  C  code  to  Actor. 

Actor's  Linkage 

While  Actor  will  call  the  same  Linkage  which  Interpret 
calls,  the  type  set  will  be  different  from  the  file  types. 

For  example,  if  the  type  is  integer  then  bundle,  state, 
storage,  and  actor  would  be  one  through  four  respectively. 
The  file  type  specified  by  the  Actor  call  to  Linkage  could 
then  be  five  to  differentiate  it  from  the  files. 

This  is  so  that  the  Share  and  Copy  functions  may  not  be 
used  but  the  code  for  renaming  need  not  be  duplicated. 

Block. 


The  module  Block  handles  all  the  sequencing  of  the 
statement  types,  along  with  the  optional  guard  and  continua 


tion  characters  enclosing  the  statement.  Its  structure 
deviates  from  the  modeling  of  D's,  because  it  is  here  that 
Wirth's  second  restriction  (mentioned  on  page  IV-8)  fails  to 
apply.  Therefore,  guard  and  statement  become  intermingled. 

Block's  flow  of  control  is  to  linkage  first,  whereupon 
local  variables  are  generated  using  the  code  sections  of  the 
state  and  storage  file  records.  Completing  this.  Block 
expects  zero  or  more  iterations  of  the  sequence  guard, 
statement,  continuation.  The  end  two  of  which  may  be  empty 
irrespective  of  the  other.  Studying  D's  syntax  one 

notes  that  guard  can  share  the  same  first  action  as  state¬ 
ment,  that  of  needing  an  expression.  This  is  what  leads  to 
the  structure  aberation. 

If  the  code  following  the  return  of  Linkage,  or  the 
parsing  and  code  generation  of  a  line,  is  not  an  expression 
indicated  by  the  token  "return",  "new",  or  "{",  then  the 
respective  function  Return,  New,  or  Block  is  called.  Should 
the  token  "$"  follow  the  return  of  Expression,  Block  will 
expect  one  of  the  four  statement  types,  otherwise  Block 
realizes  it  parsed  and  coded  a  statement  which  was  an  ex¬ 
pression,  and  skips  the  section  of  code  which  requires  a 
statement. 

Block  then  parses  and  codes  the  continuation,  if  it 
exists.  Once  completed  it  loops  back  to  the  check  for  a 
guard  or  statement,  and  continues  this  process  until  it 
detects  the  token  ">"  signifying  the  end  of  the  block. 
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Return  and  New 

Return  and  new  generate,  and  print  the  C  code  necessary 
to  perform  these  functions.  They  are  both  simple  enough  to 
code  directly,  because  the  majority  of  the  code  produced  is 
by  a  call  to  Expression. 

£1X0  r 

The  majority  of  code  this  program  will  deal  with  will 
contain  errors;  therefore  the  error  handling  should  be 
worked  into  the  design.  Basically  there  are  two  actions  the 
error  routine  produces.  The  first  is  the  writing  of  error 
messages.  For  this  operation  Error  needs  three  items  of 
information:  the  line  number  where  the  error  was  detected, 
the  token  on  which  the  error  was  detected,  and  the  type  of 
error  committed.  The  form  of  this  operation  is  a  simple 
case  statement. 

The  second  action  Error  must  complete  is  considerably 
more  difficult.  This  is  the  restart  action;  Error  must  read 
through  the  D  code  and  detect  where  is  appropriate  to  start 
the  parsing  of  the  program  again.  The  actual  decision  on 
what  restart  symbols  (or  combination  of  symbols)  are  accept¬ 
able  will  be  handled  be  that  section  of  the  code  which 
detected  the  error.  Therefore  the  fourth  argument  passed  to 
Error  will  be  the  restart  action  to  be  taken.  These  actions 
may  range  from  'do  nothing'  to  'quit  the  program'. 


Other  Functions 


The  remaining  functions  were  implicitly  or  directly 
mentioned  throughout  the  design,  but  their  discussion  has 
been  delayed  until  now.  This  was  done,  because  the  injec¬ 
tion  of  these  functions  would  have  fragmented  the  discussion 
of  the  design. 

C  unlike  many  structured  languages  is  unstructured  in 
its  organization  of  modules  permitting  them  to  be  easily 
accessed  from  anywhere  in  the  system.  This  unstructured 
approach  allows  the  creation  of  a  new  mindset  for  the 
designer.  One  may  see  C  as  having  two  distinct  function 
types,  those  that  control  the  program  sequencing,  and  those 
that  do  not.  The  latter  group  may  be  thought  of  as  tools 
providing,  in  a  sense,  macro  statements  within  the  language. 
The  algorithms  these  tools  use  are  not  important  so  long  as 
their  inputs  and  outputs  are  clearly  defined. 

For  example,  the  function  getc(ch),  in  C,  assigns  ch 
the  value  of  a  character,  and  returns  the  integer  represen¬ 
tation  of  that  character  (or  -1  for  end  of  file)  each  time 
it  is  called.  The  program  using  getc  need  not  know  how  getc 
links  to  the  operating  system  on  order  to  get  the  value, 
only  the  task  that  it  accomplishes.  Therefore,  the  tools  in 
this  system,  which  operate  on  the  structures  built,  will  be 
defined  in  terms  of  their  inputs  and  outputs  only. 

*  name_change  -  accepts  two  character  arrays.  The  func¬ 
tion  copies  whatever  is  in  the  second  array  to  the 
first.  If  the  second  array  ended  with  the  character 
sequence  '.d'  the  'd'  will  be  changed  to  a  'c'  in  the 
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first  array,  otherwise  a  '.c'  will  be  concatenated  to 
end  of  the  first  array. 


*  is_file  -  accepts  a  character  string  as  input  and 
determines  if  the  string  is  one  of  the  file  keywords. 
If  it  is  the  function  returns  a  one,  otherwise  it 
returns  a  zero. 

*  in_ list  -  accepts  a  character  string  as  a  name,  and 
the  root  of  the  file  record  structure.  It  will  search 
the  structure  for  a  file  of  the  given  name,  and  return 
one  if  it  found  it  and  zero  if  it  did  not. 

*  put_in_f ile_list  -  accepts  the  root  of  the  file  record 
structure,  a  file's  name,  and  its  type.  It  will 
create  a  new  node  for  the  named  file  in  the  proper 
alphebetical  order.  All  other  sebsections  of  the  file 
node  are  set  to  null,  and  will  be  filled  in  bey  other 
tools.  This  function  returns  the  root  of  the  list. 
This  is  handy  if  the  initial  list  is  a  null  pointer. 

*  add_rename  -  takes  the  root  of  the  renaming  list  and  a 
pair  of  names,  along  with  a  pointer  to  an  integer.  It 
adds  the  names  to  the  renaming  list  by  the  alphebetic¬ 
al  ordering  of  the  second  name,  and  returns  the  root 
of  the  list.  If  a  collision  occurs,  that  is  to  say 
the  second  name  exists  in  the  list  already,  the  inte¬ 
ger  that  is  pointed  to  is  set  ot  one,  and  the  names 
are  not  added  to  the  list. 

*  find_member  -  accepts  three  character  strings,  and 
three  pointers  to  integers,  along  with  a  structure  of 
type  members  (see  pg  IV-11).  The  strings  are  member, 
the  onput  and  output  classes  respectively,  while  the 
integers  pointed  to  are  pointer,  array,  and  function 
respectively.  Each  variable  (whether  string  or  inte¬ 
ger)  is  filled  in  with  the  appropriate  information  of 
the  object  named  member.  This  function  returns  mem¬ 
bers,  altered  by  writing  spaces  over  the  information 
extracted,  if  a  member  is  found,  and  null  if  not 

*  add_class  -  takes  the  root  of  a  vdef  list,  the  class' 
name,  the  class's  members  structure,  a  lower  and  upper 
bound.  It  adds  the  class  by  name  alphebetically  to 
the  vdef  list. 

*  add_var  -  takes  the  root  of  a  vdec  list,  the  varia¬ 
bles'  name,  its  class  (both  character  strings),  its 
level  of  indirection,  its  dimentionality  (both  inte¬ 
gers),  and  adds  the  variable  by  name  alphebetically  to 
the  vdec  list. 
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*  add_fo  -  takes  the  root  of  a  fodec  or  fodef  list,  a 
function  or  operator  name,  and  the  input  and  output 
classes  (the  last  three  being  character  strings),  and 
adds  the  function  or  operator  to  the  appropriate  list 
alphebetically  by  name  first,  then  by  input  class, 
then  by  output  class. 

The  above  three  functions  also  receive  a  pointer  to  an 
integer  as  the  last  argument,  which  gets  set  if  the  named 
objects  already  exists  in  the  list  it  is  being  added  to.  In 
addition,  all  three  also  return  the  root  of  the  list  (why? 
see  put_in_  file_list). 

*  get_file  -  accepts  a  file's  name,  and  the  root  of  the 
file  record  structure.  It  returns  a  pointer  to  the 
named  file's  node  or  a  null  depending  on  whether  it 
matched  the  name  with  one  in  the  list,  or  not. 

*  is_class  -  accepts  a  name,  a  tempory  class  (both  char¬ 
acter  strings),  and  the  root  of  a  vdef  list.  If  the 
name  is  the  temporary  class,  "null",  "int",  or  matches 
any  of  the  names  in  the  vdef  list  the  value  returned 
is  one,  otherwise  zero  is  returned. 

*  find_class  -  accepts  a  name,  and  the  root  of  a  vdef 
list,  and  returns  a  pointer  to  a  vdef  node  with  the 
name  portion  the  same  as  the  input  name,  or  null 
depending  on  whether  a  match  was  found,  or  not. 

*  find_fo  -  accepts  a  name,  and  the  root  of  fodef  or 
fodec  list,  and  returns  a  pointer  to  the  appropriate 
type  node  with  the  name  portion  the  same  as  the  input 
name,  or  null  depending  on  whether  a  match  was  made, 
or  not. 

*  find_var  -  accepts  a  name,  and  the  root  of  a  vdec 
list,  and  returns  a  pointer  to  a  vdec  node  with  the 
name  portion  the  same  as  the  input  name,  or  null 
depending  on  whether  a  match  was  found,  or  not. 

*  class  -  accepts  a  logical  name  with  C's  syntax,  and  a 
character  string  called  class.  It  extracts  the  class 
of  the  logical  name  by  parsing  the  array,  and  compar¬ 
ing  the  members  of  the  name  to  defined  structures. 
Class  (the  function)  will  return  the  class  of  the 
logical  name,  if  one  exists,  and  a  value  indicating 
the  following  conditions; 

*  0  -  the  array  is  a  valid,  defined  logical  name 
(class=class) 
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*  1  -  the  logical  name  is  not  defined  (class=null) 

*  2  -  the  logical  name  contains  a  member  which  is 

not  defined  (class=the  undefined  member) 


*  add_label  -  accepts  a  name,  an  integer,  and  the  root 
of  the  lable  list,  and  adds  the  name  to  the  list  with 
its  integer  by  alphebetic  ordering.  The  integer  is 
the  level  of  the  label  (the  name).  The  function 
returns  the  root  of  the  label  list. 

*  is_label  -  accepts  a  label  name,  a  level,  and  the  root 
of  the  label  list.  This  function  returns  a  one  if  it 
finds  a  match  of  the  label  name  with  those  in  the  list 
and  the  level  is  greater  than  or  equal  to  the  level  of 
the  matched  name,  otherwise  a  zero  is  returned. 

*  is_continuation  -  accepts  a  character  string,  and 

returns  one  if  that  string  is  or  "\", 

otherwise  the  function  returns  a  zero. 


CoaciufiiQii 

An  overall  picture  of  the  program  design  is  provided  in 
Figure  6  to  give  the  reader  a  better  feel  for  the  program 
structure.  The  tool  functions  are  not  included  as  their 
representation  would  clutter  the  picture.  Figure  6  broken 
into  multiple  sections,  including  the  tool  functions,  is 
available  in  Appendix  E. 


This  section  seeks  to  answer  three  questions:  what  are 


the  D  language’s  strengths/weaknesses;  how  was  D  changed 
during  implementation;  and  how  well  does  the  interpreter 
meet  the  expected  goals. 

An  Analysis  of.  & 

As  stated  in  earlier  sections  the  purpose  of  D  as  a 
programming  language  was  twofold.  Capt.  Jennings  believed  C 
was  somewhat  unstructured,  limited  in  its  algorithim  specif¬ 
ication,  and  nonexistent  in  its  ability  to  control  parallel 
processing;  hence,  he  attempted  to  inprove  upon  C.  In 
addition,  he  found  Ada  had  all  the  proper  enhancments,  but 
in  an  overly  large  language.  His  solution  was  to  combine 
ideas  from  the  two,  hopefully  resulting  in  a  language  re¬ 
sembling  C  in  programming  simplicity,  and  Ada  in  programming 
power.  This  goal  was  basically  met,  in  that  generic  algo¬ 
rithm  specification,  parallel  processing,  and  structured 
programming  were  achieved,  while  maintaining  a  fairly  com¬ 
pact  language.  Although,  in  an  effort  to  keep  the  language 
brief  certain  needed  or  desirable  traits  were  omitted;  these 
form  the  basis  for  D's  flaws. 

Weaknesses 

One  of  the  most  severly  chopped  sections  of  the  lan¬ 
guage  was  its  predefined  classes.  Integer  types  must  neces¬ 
sarily  be  defined  in  order  for  all  numeric  types  following 


to  be  elaborated.  As  in  Ada  the  integer  class  is  sufficient 
if  enumeration  types  are  a  part  of  the  language.  The  enum¬ 
eration  types  permit  a  mapping  of  integer  to  character. 
Unfortunately  enumeration  types  are  not  part  of  the  D  lan¬ 
guage;  therefore/  the  relationship  between  integers  and 
characters  must  be  an  abstract  one  formed  by  the  user.  Not 
only  is  this  cumbersome  for  the  user,  but  even  worse,  the 
character  string  literals  cannot  be  used,  because  the  decla¬ 
ration  of  a  variable  to  relate  to  them  is  not  possible. 

This  problem  was  probably  an  oversight,  rather  than  a  design 
mistake,  and  is  the  only  problem  which  forces  a  change. 

The  other  weaknesses  do  not  restrain  the  user  to  a 
reduced  functionality,  but  they  might  hinder  a  programmer 
from  accepting  D.  These  nuisances  are  limited  argument  pas¬ 
sing  and  awkward  type  construction. 

In  every  commonly  used  HOL  functions,  or  procedures, 
will  accept  more  than  one  argument.  The  restriction  allow¬ 
ing  a  maximum  of  one  argument  to  D  functions,  while  simpli¬ 
fying  the  interpreter,  forces  the  user  to  define  a  greater 
number  of  structures  than  is  usually  necessary.  Many  of 
these  structures  will  very  nearly  be  duplicates  of  each 
other.  On  the  other  hand,  it  could  result  in  the  definition 
of  a  few  structures,  but  allow  the  passing  of  unneeded 
variables . 

For  example,  given  Function  A  needs  variables  x,  y,  and 
z  to  operate,  Function  B  needs  variables  x,  y,  and  w,  and 


Function  C  needs  only  x  and  y,  three  structures  need  to  be 
created.  A  programmer  wishing  to  avoid  this  could  create 
one  structure  containing  x,  y,  w,  and  z,  but  this  would 
violate  a  software  engineering  principle:  do  not  allow  a 
module  to  access  data#  unless  it  needs  it.  While  the  crea¬ 
tion  of  three  structures  is  a  trival  case,  the  problem 
becomes  increasingly  menacing  when  the  combinations  of  four, 
five  or  a  greater  number  of  arguments  are  used. 

The  second  undesirable  quality  of  D  is  that  class 
construction  is  not  entirely  contained  within  the  state 
definition  file.  In  order  to  create  a  n-dimensional  array 
one  must  also  create  n-1  other  arrays  their  dimensions 
running  from  n-1  down  to  1. 

For  example,  consider  the  program  which  has  as  data 
element  a  10x20x5  space  of  integers.  The  declaration  is  as 
follows: 

int  :  xtlO] 

$ x  :  y [20] 

$y  :  space[5] 

The  intermediate  variables  x  and  y  were  necessary  to 
achieve  the  proper  declaration.  They  are  instantiated; 
therefore,  memory  space  is  allocated  for  them,  yet  they  may 
it  is  possible  they  are  never  needed.  While  runtime  memory 
is  rarely  a  problem  with  many  systems  today,  this  method  of 
declaring  variables  is  wastefull.  Furthermore  this  problem 
is  not  limited  to  the  declaration  of  multidimensional  arrays, 
but  also  includes  declarations  of  pointers  which  differ  from 


default  constructs,  e.g.  a  pointer  to  an  array. 

Though  possibly  a  problem  it  is,  perhaps,  only  a  misun¬ 
derstanding.  The  '?'  punctuation  preceeding  a  block  appears 
to  allow  a  race  condition  to  occur,  concerning  the  control 
of  a  block  following  guard  evaluation  (see  ref  5  pg  59). 
Though  this  anomaly  was  detected  early,  no  contact  was  made 
with  Capt.  Jennings  to  clarify  the  matter;  hence,  '?'  has 
been  left  unimplemented. 

Finally  the  accept  function  is  ill  defined.  One  at¬ 
tempts  to  compare  it  with  Ada'a  accept  statement,  yet  the 
definitions  do  not  seem  to  agree.  The  definition  has  been 
left  open  for  further  work,  because  C  does  not  provide 
facilities  for  tasking.  If  a  future  implementation  trans¬ 
lates  D  into  Ada  the  accept  statement  could  then  be  strictly 
defined.  For  this  version  a  D  program  containing  the  accept 
construct  will  not  be  tagged  as  wrong,  though  a  message  will 
be  generated  indicating  the  function  is  not  implemented. 

Strengths 

While  D  contains  flaws  in  its  object  definition  and 
declaration,  it  is  flexible  and  strong  in  its  algorithim 
specification.  The  actor  file,  barring  those  problems  men¬ 
tioned  above,  is  well  defined.  Its  increased  functionality 
ove  most  languages  provides  for  generic  algorithms,  and 
parallel  expression  evaluation.  Furthermore,  since  an  ex¬ 
pression  may  be  a  function  call,  D  actually  provides  a  true 
multitasking  capability. 


The  addition  of  the  operator  actor,  combined  with  the 
ability  to  overload  operator  names,  creates  very  readable 
code  using,  on  most  occasions,  standard  mathematical  prefix, 
infix,  and  suffix  operators. 

For  example  an  operator  could  be  defined,  such  that, 
the  expression  nl  would  be  understood  by  anyone  familiar 
with  factorial  notation.  Hence,  a  programmer  supplied  with 
the  necessary  operator  packages  could  implement  fomulas  in 
the  same  manner  with  which  they  appear  in  textbooks. 

Finally  overloading  of  function  or  operator  names, 
combined  with  generic  specification,  is  a  powerful  tool  for 
algorithim  representation. 

Changes  £&  B. 

As  introduced,  D  was  not  fully  developed  upon  the 
completion  of  Capt.  Jennings  thesis;  therefore,  enhancements 
(mostly  completed  definitions)  have  been  added  to  the  lan¬ 
guage  as  it  reached  the  implementation  phase. 

The  addition  of  the  predefined  class  'char'  was  added 
for  reasons  discussed  under  the  subsection  Weaknesses.  With 
this  addition,  and  the  defining  of  quoted  literal  string  as 
contants  of  type  char  it  becomes  possible  to  use  the  latter 
in  expressions.  Enumeration  types  would  also  have  provided 
a  solution  the  problem,  but  this  would  have  extended  the 
language  beyond  its  original  boundries:  a  property  desirably 
maintained  for  the  purpose  of  analyzing  D. 

In  order  to  simplyfy  the  interpreters  task  and  provide 
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a  greater  degree  of  semantic  error  checking,  an  order  was 
imposed  on  files,  object,  and  actors  (functions  and  opera¬ 
tors).  Piles  must  be  declared  in  a  bundle  file  before  they 
are  used.  Bundle  files  themselves  are  excepted;  they  and 
their  collection  of  files  must  be  defined  before  inclusion 
in  another  bundle’s  linkage  or  file  list.  The  order  in 
which  an  object  or  actor  may  appear  within  a  D  program  is 
through  declaration  (storage  file)  then  use  (actor  file). 

The  classes  or  types,  except  those  predefined,  must  appear 
in  a  state  file  prior  to  their  use  in  a  storage  or  actor 
file. 

With  the  enforcement  of  a  file  order  arose  the  need  to 
define  a  'null'  class  for  actors  which  do  not  accept  nor 
return  values.  Otherwise  the  declaration  of  such  actors 
would  be  indistinguishable  from  that  of  an  object.  An 
illustration  will  better  clarify  this  idea. 

OLD 

int  ;  get_number  could  be  a  function  returning  an 

~~  integer  or  an  integer  object 

NEW 

int  :  get_number  null  ~~  a  function  returning  an  in- 

~~  teger  while  accepting  no  input 
null  :  put_number  int  ~~  a  function  accepting  an 

integer  and  returning  no  value 
null  :  some_action  null  a  function  which  neither  ac- 

~~  cepts  input  nor  returns  output 

Finally  the  definitions  of  sharing,  copying,  and  renam¬ 
ing  were  strengthend  to  include  a  semi-global  cability  when 
used  in  a  bundle  file.  While  an  addition  of  renaming  fol¬ 
lowing  an  actor  specification,  alluded  to  on  page  40  refer- 


ence  5,  yet  not  defined  nor  allowed  in  the  syntax,  provides 
a  local  renaming  function. 


A  share,  copy,  or  rename  within  a  bundle  file's  linkage 
performs  its  respective  function  on  all  files  subsequently 
named  in  the  bundle  file's  body.  While  the  local  renaming 
will  accomplish  its  function  with  object  and  class  names 
only  within  the  scope  of  its  enclosing  actor's  definition. 

The  complete  set  of  usage  rules  for  all  changes  to  the 
D  language  are  fully  integreted  with  the  language  descrip¬ 
tion  given  in  Section  Three. 

Eunfl.tioa  va...  Specification 

Use  of  the  interpreter  built  will  quickly  reveal  the 
system  is  incomplete,  yet  many  of  the  stated  goals  have  been 
achieved.  One  of  these  goals  is  the  error  checking  and 
recovery.  The  interpreter  will  detect  any  syntax  error 
present,  provided  a  previous  error  recovery  attempt  does  not 
skip  the  interpretation  of  code,  or  derail  the  system  into 
creating  erronious  errors.  At  a  minimum  then  at  least  one 
valid  error  will  be  generated  with  each  run  of  the  interpre¬ 
ter  (if  the  code  contains  errors).  Furthermore,  the  seman¬ 
tic  error  checking  includes;  class  checking,  verification  of 
declared  variables,  check  of  members  within  structures,  and 
redefinition  or  redeclaration  of  files,  classes,  and  ob¬ 
jects.  The  only  common  semantic  check,  done  by  most  com¬ 
pilers,  not  achieved  is  type  checking  of  expressions.  This 
was  not  implemented,  because  a  full  implementation  of  the 


storage  file  is  yet  to  be  completed. 

Of  D’s  four  file  types  two  have  been  entirely  implemen¬ 
ted  (including  code  generation),  one  is  about  85%  done, 
while  the  fourth  remains  only  50-55%  complete. 

The  bundle  file  is  one  of  the  two  which  is  fully  opera¬ 
tional.  It  does  not  generate  code  as  its  function  is  to 
group  D  files  together  into  related  packages;  which  is  an 
unknown  function  in  C.  The  purpose  of  the  D  file,  initial¬ 
ly,  was  thought  to  provide  the  Unix  include  facility  within 
the  language  itself;  although,  after  study  of  the  Ada  lan¬ 
guage  it  became  evident  that  bundle  file  was  in  packaging 
D’s  files  logically.  This  implementation  accomplishes  that 
function. 

The  state  file  is  the  other  of  the  fully  implemented 
files.  Though  it  cannot  provide  the  same  function  as  in¬ 
tended,  because  of  C's  shortcommings,  the  restrictions  are 
nominal.  C  defines  all  its  functions  as  external;  the 
functions  therefore  are  globally  accessable.  This  requires 
that  the  definition  of  the  function’s  output  class  also  be 
globally  assessable.  Hence  all  structure  definitions  must 
be  coded  in  C  as  external  to  every  function.  This  is  not  as 
restrictive  as  it  appears.  It  removes  the  possibility  of 
overloading  class  names  within  different  state  files,  but 
with  the  renaming  function  name  collisions  may  be  quickly 
dispached. 

Other  than  this  restriction  the  interpreter  will  pro- 


duce  all  the  necessary  C  code  in  the  form  of  typedef  con¬ 
structs.  In  addition,  it  will  create  the  necessary  struc¬ 
tures  for  storing  the  class  information  in  the  event  the 
information  is  required  by  the  other  files. 

The  storage  file  is  the  first  of  the  incomplete  D 
files.  It  is  incomplete,  because  the  structures  used  to 
define  declared  variables  are  not  sufficient  to  hold  all  the 
possible  combinations  with  which  a  variable  may  be  declared. 
While  it  is  possible  to  declare  and  receive  the  proper  code 
for  nearly  every  variable  one  could  imagine,  there  still 
exist  a  few  for  which  this  is  not  possible,  e.g.  a  pointer 
to  a  pointer  to  an  array.  This  defficiency  stems  from  the 
impotency  of  the  state  file  to  define  all  classes. 

In  addition,  the  present  code  generated  by  the  state 
file  produces  external  variables.  This  action  voids  the 
effectiveness  of  the  copy  function.  An  easy  solution  for 
this  problem  is  available  once  the  proper  structures  needed 
for  the  storage  of  such  variables  are  defined.  This  solu¬ 
tion  will  be  discussed  in  the  concluding  remarks  as  a  guide 
to  further  work. 

Lastly  the  actor  file  is  the  farthest  from  its  final 
form.  Its  working  functions  include  parsing  of  the  D  code 
with  error  checking,  and  creation  of  the  function  specifica¬ 
tions  in  C  code.  It  is  here  that  the  type  checking  need  yet 
to  be  implemented.  Within  this  file  lies  the  strength  of  D. 
It  must  be  opened  by  interpretation  to  determine  if  the 


promises  of  a  better  language  are  true. 

Other  actions  which  were  planned  at  the  start  of  this 
project,  but  left  for  later  work  due  to  time  constraints/ 
were  the  library  of  D  functions,  the  data  dictionary,  and 
the  mapping  of  C  reserved  words  and  operator  names  into  the 
artifical  name  set  (three  underscores).  In  addition,  the 
possible  command  line  options  mentioned  in  the  requirements 
await  the  implementation  of  the  full  interpreter. 
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The  prime  motivation  for  this  thesis  was  the  implemen¬ 
tation  of  the  D  language.  Since  this  purpose  was  not  com¬ 
pleted  the  conclusion  seeks  to  provide  instruction  to  any 
follow  on  work.  Concrete  statements  cannot  be  supplied  as 
to  the  worth  of  D  at  this  stage,  but  this  thesis  brings  us 
one  step  closer  to  the  answer.  D  shows  promise,  and  de¬ 
serves  a  chance  at  life. 


First  of  all  it  should  be  noted  that  sufficient  work 
remains  to  provide  the  basis  for  another  thesis.  The  actor 
file's  code  generation  and  the  variable  declaration  struc¬ 
tures  need  to  be  implemented.  Additionally,  once  accom¬ 
plished  a  dynamic  testing  of  D  should  be  performed  to  verify 
statements  made  both  in  this  thesis  and  Capt  Jennings'  as  to 
the  languages  utility  in  a  world  glutted  with  means  for 
algorithim  expression. 


Do  It  In  Ada 

In  order  to  accomplish  such  testing  it  is  recommended 
the  future  student  rework  the  code  generation  to  produce  Ada 
code.  Within  the  final  month  of  this  report  an  unvalidated 
version  of  Ada  was  installed  on  the  Unix  Vax  computer.  It 
is  projected  that  within  the  next  few  months  (approx.  Feb- 
Mar  85)  a  fully  validated  Ada  compiler  will  be  available. 
Since  Ada  permits  tasking,  overloading  of  operator  and  func- 


VI-1 


tion  names,  sub  ranges,  and  generic  algorithm  specification, 
in  addition  to  all  functions  which  C  provides,  a  full  imple¬ 
mentation  of  D  would  be  possible.  This  is  much  preferred 
over  a  subset  as  a  true  analysis  of  D  could  take  place. 
Furthermore,  little  time  would  be  lost  as  only  the  state 
file's  code  generation  is  complete. 

The  Copy  Problem  solved 

In  the  event  further  work  continues  to  map  D  into  C  the 
global  variable  declaration  problem,  mentioned  in  Section 
Five  under  storage  files,  can  be  solved. 

If  one  separates  the  actor  declarations  from  the  varia¬ 
ble  declarations  the  variables  may  then  be  bound  into  a 
structure.  Referencing  for  variables  is  then  accomplished 
by  'storage_f ile_name.declared_variable'.  This  creates  the 
unfortunate  restriction  of  allowing  six  (seven  if  no  more 
than  30-40  copies  are  needed)  significant  characters  in  the 
storage  file  name.  This  would  supply  a  means  of  diferentia- 
tion  between  the  multiple  copies  by  the  addition  of  two 
(one)  characters  following  the  first  six  (seven)  characters 
in  the  storage  file  name.  Additional  functions  would  have 
to  be  created  to  handle  the  naming  irregularity. 

Generics  in  £ 

Though  generic  algorithims  are  not  permitted  in  C  it  is 
possible  to  interpret  the  D  program  such  that  generics  are 
supported.  To  do  so  the  program  must  keep  track  of  all 
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different  class  types  which  use  the  actor.  The  interpreter 
then  generates  the  required  number  of  copies  in  C  code 
allowing  for  the  differences  in  types.  Again  a  naming 
function/  as  with  copied  variables,  will  be  needed  to  pre¬ 
vent  name  collisions  in  the  C  code. 

In  summation  follow  on  work  is  necessary  for  the  full 
impact  and  worth  of  the  D  language,  and  this  thesis,  to  be 
realized. 
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accept  actor 
out  rename 


***** 


Keywords 


bundle  copy  in 

return  share  state 


new  null 

storage 


*****  Operators  ***** 


operator 

1 


function 
user  defined 


integer  addition  and  user  defined 
integer  subtraction  and  user  defined 
user  defined 


assignment 


combination  of  up  to  three  operator  symbols  is  possible? 
precedence  then  follows  the  rule  for  the  right  most  symbol 

precedence  is  from  the  top  of  the  operator  listing  (having  the 
highest  precedence)  to  the  bottom?  each  two  symbols  starting  at 
the  top  and  continuing  in  sets  of  two  have  the  same  precedence 
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